When you search for serials in the Serials module the results table is
often too wide for the screen (depending on your browser window size).
This is partly due to the fixed width of the search fields in the table
footer.
This patch applies a flexible width to those <input>s and reduces the
font size of their text.
This patch also moves the "action" links for each table row into an
"action" menu (similar to the change made by Bug 10615 in Reports) to
further conserve screen space.
This patch also revises the page's DataTables configuration to use table
header classes for sorting configuration.
To test you should be able to perform a search which returns multiple
open and closed subscriptions.
- Test that table sorting works correctly, including for titles with
articles and for dates.
- Test that the Action menu items work correctly and that they correctly
reflect the permissions of the logged-in user with regard to
receive_serials and routing.
- Perform these tests on both the "Open" and "Closed" tabs.
Signed-off-by: Chris <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works nicely and improves the display significantly.
Passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 2546 removes the description DB field value in some case (3.15.00.003).
But the receipt generated by scripts members/printfeercpt.pl and
members/printinvoice.pl displays this field.
When the description field is empty, the default value (based on
accountlines.accounttype) should be displayed.
Test plan:
- Generate and pay some different kinds of fees for a patron without
filling the 'description' field.
- In Fines>Account, click on the 'print' link.
- Before this patch, the "description of charges" values is empty if no
description was given.
It is a regression introduced by bug 2546, a default value was
inserted in the description field depending on the account type
selected.
- After this patch, the "description of charges" values should be based
on the account type. The string display on printing receipt should be
the same as on the account screen (staff and opac).
Note for QA: If removed the "payment" key, it is not used in template
and generated a warning ("odd number of elements...").
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
This fixes the display of payments and other charges on the
fines slip.
Note: This patch fixes a line where the description in the
database was still updated to say "Payment thanks" for partial
payments. It might be worth to do a follow-up correcting the
accountlines table and removing the unwanted comment (see bug 2546).
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch makes opacuserjs compatible with tracking tools like Piwik
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Small change to enable use of opacuserjs for statistical
tools like Piwik by moving it right above </body>.
Works as described.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The label batches editor has always sorted by the order the items were
added to a batch. However, it is now sorting by title. This should be
remedied.
Test Plan:
1) Create a label batch
2) Note the items are in order of title ( summary )
3) Apply this patch
4) Refresh the page, not the items are now sorted by label number
Tiny patch. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests, works as described.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The checkbox and "edit" column in the table of holdings on the
staff client detail page should be excluded from sorting since there is
no useful data to sort. This patch does so.
To test, view the detail page for a title which has multiple items.
Confirm that sorting works correctly.
Test under the following conditions:
- with the StaffDetailItemSelection system preference enabled and
disabled.
- as users who do and do not have cataloging item edit privileges
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as desrcibed, no problems found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When adding a duplicated patron record some fields are prepopulated from
the original patron record. Focusing your cursor on these fields
automatically clears them. This works well if you assume that the user
only focuses on fields which should be changed. This works badly if you
consider that a user might want to tab between all fields. I think the
disadvantages outweigh the minor benefit of not having to delete the
contents of a field.
This patch removes the clearing action.
TEST PLAN
---------
1) Log in to staff client
2) Patrons
3) Find an existing patron
4) Click on the link in the Name column
5) Click on the Duplicate button
6) Click on fields with data in them.
-- they will clear, which is more problematic than correcting
the entry.
7) On the line
"Home > Patrons > {patron name} > Duplicate Adult Patron"
click the patron name to go back.
8) Click on the Duplicate button
9) Tab through the fields
-- the fields should remain unchanged, but sadly they clear.
10) Apply the patch
11) On the line
"Home > Patrons > {patron name} > Duplicate Adult Patron"
click the patron name to go back.
12) Click on the Duplicate button
13) Navigate through the fields
-- tabbing nor clicking should clear any fields.
14) Run koha qa tests
NOTE: Had to rebase again. Yes, bug 7878 interfered.
However, it deals with comment #6, which Owen
appropriately noted.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Less surprises, improves accessibility by enabling to
tab through the form without losing data.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The charge with the replacement price will only be made if the charge
parameter matches the lost value. The given example is faulty (as well
as some of the code, as it appears ;)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Fixed QA script issues.
Syspref names are now camelcased and sorted correctly in sysprefs.sql.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Patch to follow that adds 3 new system preferences to control the
parameters for the longoverdue script.
New prefs are DefaultLongOverdueChargeValue, DefaultLongOverdueLostValue
and DefaultLongOverdueDays.
These preferences are used when you call the longoverdue.pl script without
their parameters.
Sponsored-By: CCSR
Signed-off-by: Leila and Fridos help <koha.aixmarseille@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Currently only the suggestion manager can order from accepted
suggestion.
This patch set to default the ability to show all suggestions when
ordering from a suggestion.
2 links "show only mine" and "show all" permits to filter/show all
permissions.
Test plan:
Create an order from a suggestion and verify you are able to see all
suggestions by default.
Verify the "show only mine" link works as expected.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
For some libraries, the current information specified in the patron
results when search for a patron to place hold is insufficient. These
libraries would like the branchcode to be added to the results to help
identify the correct patron.
Test Plan:
1) Apply this patch
2) Browse to the holds for a record
3) Search for patrons from the record holds screen
4) Note the patron results now have the branchcode after the patron type
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
I introduced this bug with my patch for Bug 8181. In changing the way
the date picker widgets worked I changed the ID the "clear date"
javascript was looking for, so it stopped working.
This patch corrects it and improves the JavaScript by moving it out of
the HTML markup.
This patch also makes some minor HTML validity corrections: escaping
ampersands and removing a "size" attribute from a hidden form field.
To test, you should have the AllowHoldDateInFuture system preference
enabled. Place a hold in the staff client for a patron and confirm that
you can choose a "hold starts on" date and a "hold expires on" date and
that the respective "clear date" links work correctly for each one.
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When OpacBrowseResults syspref is on, the detail page contains a results browser.
When search terms contains non-ASCII character, the search query is not well encoded in this browser.
This patch adds the URI-coding to search terms into session to avoid any encoding problem with diacritics and URI specific characters like ?,& ...
So that TT parameter 'busc' is already URI encoded and can be used to recreate seach URL.
Test plan :
- Set OpacBrowseResults on
- At OPAC, perform a search with a diacritique. For example 'déjà'
- Go to detail page of a result
=> You see browser under "Browser results"
- Click on "Back to results"
=> You get same results and same search term with correct encoding
Signed-off-by: Broust <jean-manuel.broust@univ-lyon2.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug still present on master. I note that latin characters are taken by ISO-8859-1 encoding
(Perl's default) and that's why real UTF8 ones don't break (Perl notices they are UTF-8).
Both of these 2 values should not be modified by the user.
Since these values depend on the discount and the quantity.
Test plan:
Verify you cannot modify the budgeted cost and the total price on
creating/modifying an order.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch simplifies the SQL query in Letters.pm for table
borrower_modifications.
It also addresses the only case this query is used in opac-memberentry.
An unused variable in Letters.pm is removed.
Test plan:
Enable selfregistration on opac.
Set verification by email to required in prefs too.
Self-register two new users.
Check the email notices generated.
Verify the new users with the tokens in their notice.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Much cleaner SQL
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Cleaner and works as described, no regressions found.
Passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
In inventory results, CSV or screen, the item withdrawn information is missing.
This information can be usefull to understand why an item was not scanned.
Test plan :
- Check you have in default framework an item subfield mapped with items.withdrawn
- Create a biblio with default framework
- Create an item with barcode='000AAA1', callnumber='ZZZAAA1' and withdrawn=0
- Create an item with barcode='000AAA2', callnumber='ZZZAAA2' and withdrawn=1
- Go to inventory tool : /cgi-bin/koha/tools/inventory.pl
- Enter item callnumber between 'ZZZ' and 'ZZZZ'
- Submit
=> You see a column 'Withdrawn' with withdrawn value
- Go to inventory tool : /cgi-bin/koha/tools/inventory.pl
- Enter item callnumber between 'ZZZ' and 'ZZZZ'
- Check 'Export to CSV file'
- Submit
- Open exported file
=> You see a column 'Withdrawn' with withdrawn value
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To reproduce this bug:
- Create a patron attribute type and limit it by patron category
- Create a new patron with that category
- Observe that there is no entry field for the patron attribute type you
created for that patron category. Inspecting the source should show
that the entry field has been hidden.
The patron entry form tries to hide patron attribute type input fields
based on the currently selected patron category. It does this based on
the value of $("categorycode"). However, instead of pulling the data
from the categorycode input in the body of the entry form, it pulls it
from the patron search box at the top of the page. The value of that
input is always empty because no category is preselected.
This patch corrects the problem by changing the ID of the categorycode
<select> in the body of the entry form and making corresponding changes
to the JavaScript which depends on it.
To test, apply the patch and load the patron entry form for a patron
category to which a patron attribute type has been limited. That patron
attribute entry field should appear correctly.
Choose a different patron category from the "Category" dropdown. Confirm
that the patron attribute entry field has been hidden.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch modifies the configuration of the staff client cart table
sorting to enable title sorting to ignore articles. Other column sorting
configuration settings are revised to use table header classes instead
of indexes.
To test, add multiple titles to the staff client cart, choosing several
titles which begin with articles ("a," "an," or "the" in English). View
the cart and test sorting of all columns. Sorting by title should sort
correctly while ignoring articles. Other columns should sort correctly
too.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script, works as described.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The MARC preview available on the staff client detail page doesn't wrap
long lines of text because it uses a huge block of whitespace-formatted
text in a <pre> tag. The OPAC doesn't have this problem because the MARC
preview is formated in a table.
This patch copies the OPAC's "plainMARC.xsl" file for use in the staff
client. The preview modal has been converted to use Bootstrap following
the method used in Bug 12755
To test, apply the patch and clear your browser cache. View the
detail page for a bibliographic record in the staff client. Click the
link to show the MARC preview. Confirm that the modal looks correct,
works correctly, and adapts gracefully to different browser widths.
Confirm that the MARC preview and Card links still work from Z39.50
searches.
Note: This patch assumes that UNIMARC records display correctly using
xslt/plainMARC.xsl. Please let me know if that is wrong.
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
I confirm it works: nice modal dialog box; display aligned on opac display;
works also with Unimarc biblios.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds two parameters to the koha-create command:
--enable-sru: makes the koha-create script enabled the SRU server for
the created instance
--sru-port: lets the user specify a desired port for the SRU server
to listen at. It defaults to 7090
To test:
- Apply the patch on top of master
- Build your own package and install / can be tested just using the koha-create
command on a 3.16+ packages install
- Create an instance as usual (i.e. without --enable-sru and --sru-port)
=> SUCCESS: The instance is created, the publicserver sections are
both commented out. The first publicserver section has 7090 set as the
listening port.
- Create an instance as usual, passing --sru-port 456
=> SUCCESS: The instance is created, the port is set but the publicserver sections
are commented out
- Create an instance with --enable-sru (with and without --sru-port)
=> SUCCESS: Verify the instance is created as expected, with the SRU server enabled
(port 7090 if no --sru-port passed, the one we chose otherwise).
- Verify that the docs also talk about this new parameters addition.
- Sign off :-D
Regards
To+
Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
In the template of the export tools, the value 'marc' is set for
the 'format' variable.
It should be 'iso2709'.
There was a mess in the tools/export.pl script.
2 variables did the same thing: $format and $output_format
This patch fixes that replacing $format with $output_format
Test plan:
Try to export biblio in iso2709 and csv using the export tools and from
the checkout list.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Before applying the patch, attemping an MARC export from tools/export.pl
resulted in an error. After the patch the export works correctly.
Exports from the checkouts page also work correctly.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script. Also tested authority export.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The "Item hasn't been transferred yet" message on circulation.pl and
moremember.pl in the holds table shows the pickup branch rather than
holding branch.
Test Plan:
1) Place an item on hold for a patron
2) Check the item in to set the hold to waiting
3) Place an item level hold for another patron,
make the pickup location be a different library
4) Load the holds tab on the patron details page for the second patron
5) Note it says "Item hasn't been transferred yet from <Pickup Library>"
6) Apply this patch
7) Repeat step 4
8) Note the library listed is now the holding library
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described and passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The suggestion date filters appear to be picking up a style change which
wasn't anticipated for the suggestions page markup. This patch solves
the problem by simplifying and standardizing the markup, including
simplifications to the label structure.
To test, apply the patch and view the suggestions management page in the
staff client. Expand the "suggestion information" filter section and
confirm that the label/input structure looks correct and works
correctly.
Signed-off-by: Blou <philippe.blouin@inlibro.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, looking better.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since bug 12986 has been pushed, the tabs don't filter correctly the
table on the saved report list (reports/guided_reports.pl?phase=Use
saved
Test plan:
Go on Reports > Guided reports wizard > Saved reports
Verify the tabs work as expected.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Confirmed problem and that the patch fixes it, passes tests
and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
prove xt/sample_notices.sql identifies missing notices. This patch add those
missing notices:
- fr-FR ISSUEQSLIP, ISSUESLIP, OPAC_REG_VERIFY, RESERVESLIP, TRANSFERSLIP
- it-IT/necessari/notices.sql: OPAC_REG_VERIFY, RENEWAL
- pl-PL/mandatory/sample_notices.sql: ISSUEQSLIP, ISSUESLIP, OPAC_REG_VERIFY,
RESERVESLIP, TRANSFERSLIP
- ru-RU/mandatory/sample_notices.sql: ISSUEQSLIP, ISSUESLIP, OPAC_REG_VERIFY,
RESERVESLIP, TRANSFERSLIP
- uk-UA/mandatory/sample_notices.sql: ISSUEQSLIP, ISSUESLIP, OPAC_REG_VERIFY,
RESERVESLIP, TRANSFERSLIP
TO TEST:
(1) Without this patch, but with the patch adding xt/sample_notices.sql:
prove xt/sample_notices.sql list all the above missing notices.
(2) Apply this patch. And do prove again: nothing is reported.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described, test stop failing
No koha-qa errors
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This test identifies incoherences between translated sample notices and the
'en' reference file.
Koha sample notices are loaded to 'letter' table from a text SQL file
during Koha installation by web installer. The reference file is the one
provided for English (en) installation :
<koha_root>/installer/data/mysql/en/mandatory/sample_notices.sql
Alternatives files are provided for other languages. Those files are difficult
to keep synchronized with reference file. This could be an functional issue
since some Koha operation depend on notice existence, for example Print Slip in
Circulation.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Test works and identify missing notices
A few koha-qa errors fixed in followup
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Without the previous patch, when you edited a patron, the "N/A" value
was selected for sex.
With, no checkboxes were selected.
This patch also replaces the
IF opduplicate do nothing ELSE do something END
statement with
UNLESS opduplicate do something END
which is more readable.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When duplicating a patron the resulting entry form contains the data
from the original patron in the following fields: Other names, Initials,
Gender, OPAC note, Staff note, and expiration date. These should be
blank for a new duplicated patron. This patch corrects this.
To test, locate or create a patron record which contains data in the
fields listed above. Duplicate that patron and confirm that those fields
are blank in the resulting patron entry form.
Confirm also that editing an existing patron with data in those fields
works correctly.
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Modified:
C4/Letters.pm - remove aqbooksellers.* from SELECT statement
In Letters - SendAlerts subrotine, is safe to remove aqbooksellers.* from SELECT statement
for type=claimacquisition or claimissues. Aqbooksellers is passed to GetPreparedLetter subrotine in tables variable.
Testing:
I Apply the patch
Select Tools -> Notices and slips;
Edit ACQCLAIM;
Add :
<order>Ordernumber <<aqorders.ordernumber>> (<<biblio.title>>) (<<aqorders.quantity>> ordered) ($<<aqorders.listprice>> <<aqbooksellers.listprice>> each) has not been received.</order>
Save modifications;
Create a vendor (Acquisition module);
Create an order (Acquisition module);
Click Acquisitions -> Late orders;
Select the order created;
Click Claim order button;
Valide <<aqorders.listprice>>;
Valide <<aqbooksellers.listprice>>.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described. It's now possible to output the actual price
in the claim notice.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If no order is selected on the acq claim page when clicking
'Claim order' an ugly perl error message is displayed.
This patch corrects the behaviour to display a human readable
'No order selected'
instead.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Reworded commit message to reflect what the patch achieves.
Works as described and passes tests.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds the budget name to the page heading when editing a
budget. The patch also similarly corrects the page title during edit
operations and fixes some inconsistency in the breadcrumbs.
To test, edit an existing budget (Adminitration -> Budgets) and confirm
that page title, breadcrumbs, and heading look correct.
Signed-off-by: Chris <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Nice improvement, works as described.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds a better check in message for patrons with indefinite restriction.
To test:
Check out an item to a patron.
Add a manual restriction without expiry date to that patron.
Check in the item.
Without patch, the checkin message reads:
Reminder: Patron was earlier restricted until 9999-12-31
Apply patch and repeat steps above.
The message should now read:
Reminder: Patron has a restriction (no expiry date)
NOTE: Changed wording at two places following Owen's suggestion. New: "Patron
has an indefinite restriction"
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Thanks Marc for catching this case. I was thinking like you that the wording
sounded strange while playing with bug 13242. Merge the original patch and the
followup, containing a better wording, thanks to Owen comment.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, no problems found.
Passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If the opacreadinghistory system preference is turned off it is still
possible to navigate directly to the OPAC reading history page if you
know the URL. This patch adapts the fix for Bug 10595 (OpacTopissue page
still accessible when system preference is turned off) for
opac-readingrecord.pl
To test, log in to the OPAC and test the following conditions:
- With opacreadinghistory, navigating directly to
/cgi-bin/koha/opac-readingrecord.pl should trigger a 404 error.
- With opacreadinghistory turned on there should be a working link to
"your reading history" in the left-hand sidebar menu.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described and passes tests.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If the OPACPrivacy system preference is turned off it is still possible
to navigate directly to the OPAC privacy page if you know the URL. This
patch adapts the fix for Bug 10595 (OpacTopissue page still
accessible when system preference is turned off) for opac-privacy.pl
Because the OPACPrivacy preference is irrelevant if opacreadinghistory
is not turned on, the patch adds a check for both to determine whether
the page should be accessible.
Log in to the OPAC and test under the following conditions:
- OPACPrivacy is turned off, opacreadinghistory is turned off. Navigate
directly to /cgi-bin/koha/opac-privacy.pl. You should get a 404
error.
- OPACPrivacy is turned off, opacreadinghistory is turned on. Navigate
directly to /cgi-bin/koha/opac-privacy.pl. You should get a 404
error.
- OPACPrivacy is turned on, opacreadinghistory is turned off. Navigate
directly to /cgi-bin/koha/opac-privacy.pl. You should get a 404
error.
- OPACPrivacy is turned on, opacreadinghistory is turned on. A link to
both "your reading history" and "your privacy" should appear in the
left-hand sidebar menu. Both pages should work.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes tests and qa script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The document.write in a td seems to brake the page with a new version of
DataTables.
This patch replaces a dirty piece of code with another one (but this one
works...)
Test plan:
Create repeatable holidays and verify the page loads correctly.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Works to fix the problem. The code is definitely an improvement.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, fixes critical problem.
Passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If you have the SpecifyDueDate preference disabled and check something
out as an on-site checkout the due date seems to follow the default
circulation rule rather than restricted the checkout to that day.
Test plan:
0/ Disable SpecifyDueDate and enable OnSiteCheckouts
1/ Check an item out to a patron and check the 'On-site checkout'
checkbox
2/ Verify (screen and DB) that the due date is correct (today 23:59)
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To reproduce:
- Stop your MySQL server:
$ sudo service mysql stop
- Run
$ prove t/SuggestionEngine_AuthorityFile.t
=> FAIL: some tests fail because of mysql stopped
To test (MySQL still stopped)
- Apply the patch
- Run
$ prove t/SuggestionEngine_AuthorityFile.t
=> SUCCESS: tests pass because the ycan be loaded regardless of
the absence of the DB server
- Sign off :-D
Regards
Signed-off-by: Magnus Enger <digitalutvikling@gmail.com>
Turned off MySQL and ran the tests before and after the patch.
Works as advertized.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
