Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds:
- 1 syspref MarcFieldsToOrder
- 1 Ajax script acqui/ajax-getauthvaluedropbox.pl
- 1 routine C4::Budgets::GetBudgetByCode
Before this patch you were not able to order 1 or all the records from
your staged file. You were allowed to specify some information ("Import
All" and "Accounting details" areas) for the order.
With this patch, the previous behaviour still exists.
But now you can *select* which records you want to ordered.
For these ones you can specify independently quantity,
price, budget, sort1 and sort2.
The cherry on the cake is that you can pre-fill these fields with
values from the MARC record.
Test plan:
1. Fill the new syspref MarcFieldsToOrder with something like:
==BEGIN==
price: 947$c
quantity: 969$h
budget_code: 922$a
rrp: 010$d
discount: 969$d
sort1: 923$a
sort2: 924$a
==END==
The empty line at the end is mandatory!
The budget (corresponding to your budget_code) can be filled with
authorized value categories (statistic 1 and 2).
The sort1 and sort2 values can be filled with the an authorized value
(of the category previously selected)
2. Choose randomly one or more biblio(s) and fill fields with what is
relevant.
3. Export the biblio and import it (with the "Stage MARC records for
import" tool).
4. Go on a basket and add an order from a staged file. Select your
staged file.
5. Well. Now you can see your biblio (or biblios if your had exported
more than one). For each one, fields should be pre-filled with the
biblio values. The budget should be selected on the budget
corresponding to the budget_code (in the field 922$a) and the
"planning values" too (with fields 923$a and 924$a).
You can modify these values (or not) and choose a default value for
budget and planning values (in the "Accounting details" area).
6. Save and check the prices values. Modify the order and check that
budget and sort* are good
Prices are calculated following some parameters:
if there is no price => listprice = 0
else =>
- the gstrate value for your order is the gstrate value of the bookseller
- discount = if filled : the discount value / 100
else: the discount value of the bookseller
- if the bookseller includes tax( List item price includes tax: Yes )
if a discount exists:
ecost = price
rrp = ecost / ( 1 - discount )
else: # a discount does not exist
ecost = price * ( 1 - discount )
rrp = price
else # the bookseller does not include tax
if a discount exists:
ecost = price / ( 1 + gstrate )
rrp = ecost / ( 1 - discount )
else: # a discount does not exist
rrp = price / ( 1 + gstrate )
ecost = rrp * ( 1 - discount )
- in all cases:
listprice = rrp / currency rate
unitprice = ecost
total = ecost * quantity
7. Retry with different parameters
8. Check the 'Import all' action still works
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Before this patch, the C4::Budgets::CanUserUseBudget assumed that
budget_owner_id was set if a restriction (budget_permission) exists.
see
&& $budget->{budget_owner_id}
&& $budget->{budget_owner_id} != $borrower->{borrowernumber}
Actually a restriction could exists on users and/or library without
being forced to define an owner.
Test plan:
Create a fund A without restriction
Create a fund B restricted to an owner
Create a fund C restricted to a non defined owner
Create a fund D restricted to owner and users (try defining/no
defining an owner and/or users)
Create a fund E restricted to owner, users and library (try
defining/no defined an owner and/or users)
With different logged in users, try to show/edit these differents funds.
The restriction should be correctly applied.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested various permission combinatons, visibility of funds is now ok.
- not superlibrarian, no buget_manage_all,
no owner, no users, no library, no restrictions on the fund
= visible
- changed: library = staff patron library,
restriction = Owner, users and library
= visible
- changed: library = not staff patron library
= invisible
- changed: budget_manage_all
= visible
- changed: owner = staff patron
no budget_manage_all
= visible
- changed: no owner, user = staff patron
= visible
- changed: no user, owner = another user, restriction = owner
= invisible
- changed: budget_manage_all
= visible
- changed: no budget_manage_all but superlibrarian
= visible
...
Passes tests and QA script, also t/Budgets/*
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The current funds list view does not allow to search in the table and
the ergonomics of the page is quite bad.
This patch add the datatables plugin combined to the treetable plugin in
order to offer a better view of the budgets/funds.
Test plan:
- Verify there is no regression on this page: try to add/modify/delete a
fund and a budget.
- Verify the funds hierarchy is correctly displayed.
- Filter the funds using the branch and the budget filters.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Sometimes libraries need to backdate returns further back in time than
Koha's dropbox mode will allow. The returns backdating will check in an
item as if it had been returned on the specified date, and will reduce
any fine accordingly.
This feature is activated by a new system preference, SpecifyReturnDate.
Test Plan:
1) Apply this patch
2) Check out an item, and backdate the due date by 1 month or so
* This issue needs to generate a fine
3) Run fines.pl to generate the fine
4) Browse to returns.pl
5) Specify a return date of the day after the specified due date
6) Check the borrowers issue history, you should see the backdated
return date, rather than today's date
7) Check the fine, it should be reduced to a fine for a single day
overdue, rather than the previous larger fine.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Barbara Knibbs <BKnibbs@farmingtonlibraries.org>
Signed-off-by: Petter Goksoyr Asen <boutrosboutrosboutros@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes tests and QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch fixes a situation where a patron that has preferences
set for transport of a notice via a method that is not supported
for that notice type can result in a failure. Rather than
make it a fatal error during checkin, simply log a warning and skip.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This reordering avoids the case where a print notice is sent with an
email or sms template is no email or SMS is defined.
Test plan:
Check print, sms and email for an overdue rule
Don't define an email address and generate an overdue for a user
Define 3 templates for the notice used
Launch the cronjob script and verify the print notice is generated using
the print template.
Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch prevents duplicate hold available print notices from being
sent and enforces making a print notice if no other transports can be
used.
-------------------------
- REPLICATING THE ISSUE -
-------------------------
1. Set a Patrons "Hold filled"-messaging preference to SMS + Email
2. Remove the SMS number (sms notification number) and all email
addresses.
3. Make a reservation for this Patron.
4. Check-in the reserved Item.
5. message_queue-table has two generated print notices for the
Hold_filled event.
One for both failed message transport types, email and sms.
1. Set a Patrons "Hold filled"-messaging preference to empty, remove all
checks from boxes.
2. Make a reservation for this Patron
3. Check-in the reserved Item.
4. message_queue-table has no message for the Hold-filled event. This is
problematic because a Patron should get some kind of a notification
for a filled Hold.
-----------------------------
- AFTER APPLYING THIS PATCH -
-----------------------------
If all message transport types for "Hold filled" fail, a print notice is
queued in the message_queue table. Only one print message is queued even
if many transports attempts fail.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The HOLD_PRINT and HOLD_PHONE notices become useless.
This patch modifies existing notices in order to group them into the
main notice type 'HOLD', with any pre-existing print and phone
templates in the appropriate places.
Test plan:
- Apply the patch and execute the update database entry.
- Verify that your previous HOLD_PHONE and HOLD_PRINT are displayed
when editing the HOLD notice (under phone and print).
- Choose a patron and check SMS, email, phone for "Hold filled"
(on the patron messaging preferences).
- Place a hold.
- Check the item in and confirm the hold.
- If the patron has an email *and* a SMS number, 2 new messages are put
into the message_queue table: 1 sms and 1 email.
If the patron does not have 1 of them, there are 2 new messages: 1
sms/email and 1 print.
If the user has neither of them, there is 1 new message: 1 print.
- The generated messages should correspond with the notices defined,
depending the message transport type.
Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Just noting that if email and SMS are disabled in the msg prefs, the user
will not have a print message.
And if the SMS driver fails, the record status in message_queue is 'failed',
but staff may not be aware of that.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
GetLetters only returns letters with a mtt = email. It should return all
letter codes in the DB.
The message_transport_type parameter is never used.
To reproduce the issue:
Create a notice with a sms template and no email template.
Go on the overdue rules configucation page.
The notice does not appear in the notice list.
Signed-off-by: Olli-Antti Kivilahti <kivilahtio@ProBook6570b>
---------------
Testing report:
---------------
Testing this subroutine from a test stub. Calling the method without arguments
and with argument 'circulation' and 'circulat'.
Works as supposed to.
Related Bug 11931 discovered but not within the scope of this featureset.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
* Fixes POD of GetMessageTransportTypes.
* Removes the useless map in GetMessageTransportTypes.
* Textual: "You must specify a title and a content" ->
"Please specify title and content".
* Reintroduces << and >> around the field name.
* Change message for the update DB entry.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The unit tests should insert overdue rules.
+ Fix the doc for GetOverdueMessageTransportTypes
Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds:
- a new routine C4::Overdues::GetOverdueMessageTransportTypes.
- the ability to define one or more transport types for an overdue
level.
Test plan:
- go on tools/overduerules.pl.
- verify that previous rules still exist and that the 'email' checkboxes
is checked if a rule is defined.
- redefined rules at different levels and check the transport type
needed. Currently, only email, sms and print are relevant
- Save the changes.
Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds:
- a new jquery plugin : insertatcaret.
- the ability to define a notice template for each transport type.
- a new routine C4::Letters::GetMessageTransportTypes.
Test plan:
- Go on tools/letter.pl and check that all existing notices are still
there.
- Modify one. A new empty message is present for sms, print, etc. The
email message is filled with the existant value.
- Add a message for sms for example (don't forget the subject) and save.
- edit again and verify the sms message has been saved.
Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch fixes various issues that prevented the account
type from being set correctly when recording SIP2 payments:
- the fixed fields in the fee paid message were not getting
parsed correclty
- accountlines.accounttype is only five characters wide, so
SIP2 payments are now records as 'Pay00', 'Pay02', etc. rather
than 'Pay-00'.
- removed regression on bug 2546 and made the new payment types
translatable
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Adds support for recording in Koha accountlines a different accounttype
depending on how the fee was paid at the SIP2 station (cash, credit,
etc.)
Adds a new param to recordpayment(), $sip_paytype, which is appended to
the 'Pay' type if present. The payment description is also appended
with " (via SIP2)" if this is present.
In order for other scripts to keep working as expected, "eq 'Pay'"
needed to be replaced with a regex comparison "=~ /^Pay/", so that 'Pay'
and 'Pay-##' would continue to group together.
To test:
1. Make a payment over a SIP2 connection
2. Check the patron record in the staff client; you should see the
modified description
3. Attempt to print a invoice or a reciept for the borrower; the
payment should show up where expected
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The accounts->login tag in SIPconfig.xml can now accept a new
parameter, "encoding". It will be mostly used to encode to utf8.
For this, simply add the parameter: encoding="utf8"
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Works as advertised, does nothing if encoding is not set.
Blows up all the machines that can't handled utf8 if it is set :) But
that's not Koha's fault. :)
Patch rebased by Christophe Croullebois <christophe.croullebois@biblibre.com>
Signed-off-by: Petter Goksoyr Asen <boutrosboutrosboutros@gmail.com>
But now I did it the right way! And I can confirm that this patch solves
all issues with mangled characters in SIP messages. Confirmed that it
looks good with Norwegian characters in patron name and in book titles.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The current "Library" facet is somewhat ambiguous for Koha installations
with multiple libraries. It refers to the holdingbranch, but does not
explicitly state this. It would be beneficial to allow the administrator
to choose to show facets for the holding library, home library, or both.
In addition, the facets should be more explicitly labeled. This patch
adds this flexibility.
Test plan:
1) Apply this patch
2) Check that the facets label "Libraries" now reads "Holding libraries"
3) Update the system preference DisplayLibraryFacets to "home library"
4) Check that the facet now reads "Home libraries"
5) Update the preference again to "both home and holding library"
6) Check that both the facets for home and holding library are now
displayed.
Signed-off-by: Jen DeMuth <jdemuth@roseville.ca.us>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Changes apply to both prog and bootstrap OPAC and staff client.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Location facet in UNIMARC is void. In the code, it is build
on 995$c, while location is store in 995$e (see record.abs).
This patch replace 995$c with 995$e in Koha.pm
To test :
1. Use a UNIMARC Koha instance with ONE branch, and SEVERAL
locations
2. Make a search in opac and staff interface : no location
facet on the left side of the screen
3. apply the patch
4. Make the same search : location facets will be displayed
NOTE: I, Mark Tompsett, rebased this. I confirmed that 995$c
should be 995$e (wiki, Holdings_data_fields_(9xx) page)
Also note that the code relocated based on bug 10078,
causing the patch to not apply.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
NOTE: The location facet did not appear in master, but after
applying the patch, it did appear.
Because of the code being moved, it is no longer affected
by the branch count or singleBranchMode.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixes wrong subfield code for UNIMARC.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch fixes a regression on bug 5603 introduced by
the previous patch by ensuring that if no preferred transports are
active for a given message, GetMessagingPreferences()
won't try to populate the transports hash with an undef hash
key.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
If you have enhanced messaging preference, the Days in Advance combo
value (in Patron Messaging Preferences) is saved in the database but
not retrieved when you have not enabled the Email checkbox (or checkbox
for any other transport) next to it.
This patch does the following:
[1] It replaces a JOIN by a LEFT JOIN that is the actual reason of the
problem described.
[2] Removes a FIXME by saving a hardcoded 30 into a constant.
[3] Fixes a typo in the neighborhood.
[4] Removes a superfluous comma in the map statement.
[5] Simplifies code for the selected field of the days combo. It should
just be a boolean. The text selected="selected" is in the template.
Test plan:
[1] Enable enhanced messaging preferences.
[2] Fill in Days in advance for Advance notice but uncheck Email.
[3] Save the preferences.
[4] The member home screen does not display the number of days (until you
decide to apply this patch :)
Followed test plan. Works as expected.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch removes instances of dt_add_type_uk_date() from acquisitions
templates and updates sorting configurations according to current
guidelines.
In cases where a formatted date was passed from a Perl script, the
script has been modified to pass an unformatted date.
Several instances of the no longer valid align attribute have been
removed from <td> tags in favor of an existing "data" class which is
suitable for display of currency values.
To test, view the following pages in Acquisitions. Columns containing
dates should sort correctly regardless of dateformat system preference
setting. Columns containing bibliographic titles should ignore articles
when sorting.
- Add to an order from a staged file: The table of staged files should
sort correctly. After clicking "add orders" for one of the staged
files, the table of titles in that staged file should also be sorted
correctly.
- Add to an order from a subscription. The table of subscription search
results should sort correctly.
- Orders search results should sort correctly.
- Late orders should sort correctly.
- Search for a vendor. Click on the vendor name to view the vendor
detail page. The table of contracts on this page should sort
correctly.
- From the Acquisitions home page click a number in the "spent" column
of the table of available funds. The table of orders should sort
correctly.
- From the Acquisitions home page click a number in the "ordered" column
of the table of available funds. The table of orders should sort
correctly.
- From a vendor detail page, click the "Receive shipments" button. On
the receive shipments page the table of shipments should be sorted
correctly.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10649 introduced a new include file for adding DataTables-related
JavaScript assets. This patch adds use of this include file to all
serials-related pages which use DataTables.
Apply the patch and test the following pages to confirm that table
sorting works correctly:
- Serials search results (serials/serials-search.pl): Perform a search
which will return more than one subscription. The expiration date
column is now sorted using the "title-string" filter for sorting based
on the unformatted date. The "anti-the" filter has been added to the
title column to exclude articles when sorting.
- Serials collection (serials/serials-collection.pl): View the serial
colection page for an existing subscription. The table of issues
should be sorted correctly.
- Serial claims (serials/claims.pl): The "since" and
"claim date" columns have been modified to use the title-string filter
for sorting based on the unformatted date.
C4::Serials.pm::GetLateOrMissingIssues has been modified to pass an
unformatted date along with the formatted date. The "anti-the" filter
has been added to the title column to exclude articles when sorting.
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested all 3 tables, no regressions found.
Passes QA script and tests.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Koha's SIP2 server implementation does not currently support the SIP2
protocol field "media type" ( CK ).
This patch implements the SIP2 media type by allowing an arbitrary
mapping of itemtypes to SIP2 media types.
Test Plan:
1) Apply this patch
2) Run updatedatabase
3) Edit an itemtype, select a SIP media type, and save the changes
4) Make a SIP2 Item Information Request
5) Verify that the CK field of the Item Information Response contains
the correct media type code.
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
C4::TmplToken depends on Exporter but does not use any
of its facilities. Removed the dead code so it does not
clog up the source and waste compilation time
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Module still compiles correctly; t/TmplToken.t passes.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch removes the ImportBreeding() routine, which lost its
last caller as of the patch for bug 10462.
To test:
[1] Verify that prove -v t/Breeding.t passes.
[2] Perform a Z39.50 search in the staff interface.
[3] Perform a cataloguing reservoir search in the staff
interface; verifying that cached records from the search
done in step 2 are retrieved.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch clarifies the logic for determining if a given item to be
checked out would be the second (or third, etc.) loan on the same bib.
As a conseqence, if the item is already on loan to the patron, the
circ staffer won't see the multiple-loans-on-a-bib warning, just
the confirmation to renew the loan or the warning that no more
renewals are lest.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds a new system preference, AllowMultipleIssuesOnABiblio.
If this system preference is OFF, an alert is raised if a patron
tries to check out an item even when they already have a different
item checked out from that bib.
The librarian can force the checkout anyway.
It doesn't alert the librarian if the biblio is a subscription
Test plan:
1. Create a biblio with at least 2 items
2. Checkout the first item for a borrower
3. Set syspref AllowMultipleIssuesOnABiblio to OFF.
4. Try to checkout the second item with the same borrower. A message
should appear telling you that this borrower already borrowed an item
from this biblio.
If you have the permission 'force_checkout' You should also see two
buttons to confirm (or not) the checkout
5. Click on 'No'. The checkout is not done
6. Repeat step 4 and click 'Yes', the checkout is done.
7. Return the second item.
8. Set syspref AllowMultipleIssuesOnABiblio to ON
9. Try to checkout the second item with the same borrower. This time
the checkout is done without warnings.
Followed test plan. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass, works well. Tested:
* Permission to override
* check out a second item from a record with subscriptions works
* check out a second item from a 'normal' record is warned about,
but can be done
* No permission to override
* subscription item: can be checked out
* normal item: can't be checked out
* Feature turned off
* Check out never warns/blocks
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
- Fix syntax error in supplied test
- remove subscriptionid as a field returned by GetInvoices(), as
the is_linked_to_subscriptions Boolean takes its place.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
If an invoice is linked to subscription, we need to set a boolean to
true in order to filter them in the interface.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds a checkbox "Show only subscriptions" in the invoices
table.
If this checkbox is checked, only invoices that contain at least one
order linked to a subscription are displayed.
To test:
- Test in a database with multiple existing invoices
- Create an order from a subscription, close basket, receive
- Test that the result table of the invoice search shows
the new checkbox and that it works correctly
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch makes 4 changes in late orders page :
- adding a new column for basketgroup, displaying
the name and number of the basketgroup
- displaying the name of the basket as well as its
number, with a hyperlink to this basket
- displaying fund in a separate column to make
sorting easier, and renaming it from "budget" to
"fund" (the confusion can be found elsewhere in Koha...)
- displaying branch in a separate column to make
sorting easier (this column could be improved later,
by getting branch from basketgroup if there is one)
For that, in Aquisition.pm, I made some changes to GetLateOrders:
- 3 new columns in SELECT
- 1 new join
To test :
1. Display the list of late orders of your instance.
2. Check you have 3 new columns for basketgroups, fund and branch
3. In basketgroup column you should have "name of basket group (number)"
4. In basket column you should have "name of basket (number)"
5. Check the links for basketgroups. They should send you to the
page displaying information for each basketgroup
(without possibiliy of editing them if they are closed)
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Patches pass QA script and all tests.
Works as described. Also checked sorting and orders which
are not in a basketgroup display correctly.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
It is now possible to search on the order number on the order search
page.
Also searching on parent_ordernumber is possible, allowing one to
search to search children for a given order number.
Test plan:
1/ create a basket and 1 order with at least 2 items.
2/ receive partialy the order (receive only 1 item).
3/ note that a new ordernumber is created for item not received.
4/ go on the order search form and search for the original ordernumber
without checking the new checkbox "Display children too." => only 1
order (the parent) is displayed.
5/ now check the checkbox and search again => the parent order is
displayed but children too.
Signed-off-by: remy juliette <juliette.levast@iepg.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works nicely, passes all tests and QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
admin/aqbudgets.pl should have the following columns:
Base-level allocated (or just Allocated)
Base-level ordered
Total sub-levels ordered
Base-level spent
Total sub-levels spent
Base-level available
Total sub-levels available
Base-level is always calculated for one level, without children.
Total sub-levels should include child funds.
Available is calculated as "allocated - (ordered + spent)".
Signed-off-by: Cedric Vita <cedric.vita@dracenie.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Seems to work alright for me.
Passes QA script and tests, after I fixed 2 tabs in admin/aqbudgets.pl.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
If an order is transferred from one basket to another, it should be
possible to retrieve it with the original order number (AKA order
line). This patch makes it so.
Test plan:
- transfer an order
- note the original order number and the new one
- receive the order and, on the parcel page, try to find your order with
the original order number and the new one.
Signed-off-by: sonia bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
RM note: this works only for the most recent transfer, so if an order
gets transferred multiple times, earlier order numbers won't retrieve
it.
Since kohaadmin has no borrower number, it cannot create lists.
A database error is logged, but the user is not notified.
This patch alerts the user.
In the incidental case that a normal user gets a database error,
they are notified too that the list could not be created.
Test plan (for prog and bootstrap):
* This patch should be applied on top of 9032 patches.
* Login as as the database admin user
* Create a list in opac and staff. Check the message.
* Login as a normal user.
* Force a database error on list creation (I renamed category
in the table with alter table change column..)
* You should have a different error message.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes tests and QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch teaches C4::Reports::Guided::execute_query()
how to accept a list of query parameter values. It then
follows-up on the main patch by simplifying how it converts
report parameters to a complete SQL query, and removes the
use of DBI->quote() and complicated regexes.
To test:
[1] Verify that using the OPAC svc/report service with
sql_params continues to work.
[2] Verify that there are no regressions with running
reports from the staff interface, both via the web
service and the reports interface.
[3] Verify that prove -v /db_dependent/Reports_Guided.t passes.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
No regressions found.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The sharedate column is documented as having the following meaning:
"date of invitation or acceptance of invitation"
This patch adjust the new list-sharing code to stick with that
interpretation, as otherwise the column should have been renamed
to 'invite_expiration_date' or the like.
It also removes the "housekeeping" functionality from AddShare, as
otherwise the routine should have been named AddShareAndDoOtherStuff.
To prevent list shares from piling up, a new --list-invites flag
has been added to cleanup_database.pl. The default crontabs have
been modified to use the --list-invites flag by default.
To test
-------
[1] Make some list share invites and accept some, but now all of them.
[2] Wait 14 days (or more reasonably, manually edit the sharedate
values for the unaccepted shares to put them at least 14 days in the
past.).
[3] Run cleanup_database.pl --list-invites
[4] Verify that accepted shares remain, as to share invites that have
not yet reached more than 14 days of age.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
DelShelf deletes a list regardless whether it is private, shared or
public. HandleDelBorrower had another approach, trying to save shared
and public lists by setting the owner to NULL.
This patch makes both routines behave consistently.
A new report 11889 has been opened to discuss the 'disowning' feature.
NOTE: I did not add a db revision here to handle possible cases of lists
without owner in the current data. Such public (or shared) lists can still
be used without any problem. Bug 11889 and a new planned report for a lists
management tool will address this topic further on. After that, all goals
of umbrella report 7310 should be realized.
Test plan:
Create a list P1 with user1 that allows adding by other users.
Add a patron (user2).
Login as user2 and create some lists, add some items.
Let user2 add some entries to P1 too.
Delete patron user2.
Verify that his lists are gone, but his entries in P1 are kept (nullified).
Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch handles:
[1] The response (acceptance) by the invited person.
If the person accepts this share, the private list of the sender will
be shown under Your lists on the shelves page. In OPAC 'Your private
lists' has been renamed to Your lists (just as in Staff). The Type
column shows Private or Shared for these lists; a list appears as
Shared as soon as an invitation has been accepted. The owner has the
options to Edit, Delete or Share; the invited person does not have
these options on the shared list.
[2] Removing an accepted share.
If a user accepted a share, they should also be able to remove it again.
The Remove Share button is visible on OPAC when viewing Your lists or
a particular shared list.
Note: AddShare has been extended to return a possible database error.
If the share invite could not be added, a mail will not be sent.
Test plan (for prog theme):
Enable pref OpacAllowSharingPrivateLists
User 1 creates new private list P1, perms: D-A-D, adds 2 items, sends share
User 1 checks your lists display: is P1 Private with Edit button?
User 2 accepts share: sees P1, but cannot add or delete items
User 2 checks your lists display again: P1 shows Shared without Edit?
User 1 checks your lists display again: P1 shows Shared with Edit?
User 2 tries to accept share again: should fail now
User 3 tries to accept share: should also fail
User 3 tries again, modifies shelfnumber and/or key in url: should also fail
User 2 creates new private list P2, perms: A-A-A, no items, sends share
User 2 checks your lists display: P2 shows Private with Edit?
User 1 accepts, adds one item
User 1 checks your lists display: P2 shows Shared without Edit?
User 2 checks your lists display: P2 shows Shared with Edit?
User 2 deletes item of user 1 (allowed)
User 2 deletes list P2
User 1 checks your lists display in opac or staff: P2 is gone?
User 1 creates private list P3, sends a share.
User 1 creates private list P4, adds one item, sends a share.
User 2 accepts the share for P3.
User 2 checks the shelves display, and removes share P3.
User 2 accepts the share for P4.
User 2 views shelf P4 with one item and confirms Remove share on that form.
User 2 checks shelves display again.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Just adds this dependency to PerlDependencies module.
Note from Robin: libemail-valid-perl is in squeeze already.
Test plan:
You should see Email::Valid now under About/Perl modules.
If Email::Valid is not yet installed on your system, please do so.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
