This patch updates the issue notices to not pass from_address and so
default to the branch email of the user for from_address. We now pass
the patrons email (cascading through email, emailpro, B_email) into the
reply_address field so mail servers are less likely to report emails as
spam and mail clients still have access to the patron address via the
reply-to header when staff want to hit 'reply' and have the email go to
the user.
Signed-off-by: Myka Kennedy Stephens <mkstephens@lancasterseminary.edu>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
I have the feeling that we should return undef here, but can be ignored
if someone disagrees.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Make the name obvious it's not an email address for "from"
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Add a `get_effective_email` method to the Koha::Library object which
returns the email address for the library which they are most likely to
have access to.
This method falls back through preferences `branchreplyto`, `branchemail`,
`ReplytoDefault`, `KohaAdminEmailAddress`.
This bug simply introduces a new utility function to return the most effective email address for a branch to be emailed on.
Test plan
1/ Read the new test and verify it makes sense
2/ Run the tests and verify they all pass.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds unit tests for the newly introduced get_effective_email
method in the Koha::Library class.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch updates the EnqueueLetter method to allow passing a reply_to
address. This allows for passing in arbitrary addresses for the reply
address which will not override the from address. This improves the
chances of your email getting past spam filters.
Signed-off-by: Myka Kennedy Stephens <mkstephens@lancasterseminary.edu>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch changes the text of the "Collect from patron" field to read "Amount tendered"
To Test:
1) In the Point of Sale screen, check that the text inside the "Collect payment" box reads "Collect from patron"
2) Go into a patron record, and create a manual invoice.
3) Go to Make a payment, and select to "Pay an amount". Check the text reads "Collect from patron".
4) Repeat the process with the "Pay Selected", and "Pay" button (listed next to the individual invoice)
5) Install the patch
6) Repeat steps 1-4, but the text should now read "Amount tendered", instead of "Collect from patron" in all payment options in the patron record, and in the Point of Sale screen.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
TEST PLAN:
1. Apply patch
2. Have some checkout from today and some from multiple previous days.
3. Set todaysIssuesDefaultSortOrder & previousIssuesDefaultSortOrder to 'earliest to latest' and confirm it sorts correctly.
4. Reverse the 2 system preferences and see that it is now sorting the opposite way.
5. Also look at the wording of each system prefence and make sure it makes sense
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
And build_sample_item.
Also remove a debug statement
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
test plan :
1/ Submit a hold through ILSDI with start_date and expiry_date parameters
2/ Verify in Koha those parameters are not applied to the newly created
reserve. Delete reserve.
3/ Apply patch and repeat 1.
4/ Verify the reserve created by same request as 1 now has both dates
applied and visible in Koha.
Signed-off-by: Christophe Croullebois <christophe.croullebois@biblibre.com>
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
When importing records and looking for duplicate records using record matching rules,
there is an option if NO match is found to "ignore incoming record (its items may
still be processed)". This doesn't make any sense. Where would the items go if there
is no match?
To test:
1) Go to Tools > Stage MARC for import
2) Browse and choose a file with at least one record that is not already in your
catalog and click on Upload file
3) Fill out the first section with the appropriate information
4) In the Look for existing records in catalog? section, choose a record matching
rule
5) In the Action if no match is found drop-down menu, choose Ignore incoming record
(its items may still be processed)
6) Click on Stage for import
7) Click on Manage staged records
8) Click Import this batch in the catalog
9) In the table, the record status should say Ignore
10) Apply patch
11) Redo steps 1-9, notice the option Ignore incoming records does not mention items
12) Make sure the tool still works and still ignores the record
Signed-off-by: Devinim <kohadevinim@devinim.com.tr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This field is never NULL and must always be equal to an integer.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
I am trying to make koha-testing-docker UNIMARC compabible.
In order to have koha-misc4dev insert all the data correctly (users, etc.) we need at least 1 library.
I am suggesting to reuse the usual library list for UNIMARC.
misc4dev will use fr-FR sample data for "UNIMARC"
This is related to https://gitlab.com/koha-community/koha-misc4dev/issues/29
Test plan:
outside your box, in koha-testing-docker (up-to-date), edit .env and set
KOHA_MARC_FLAVOUR=unimarc
DEBUG_GIT_REPO_MISC4DEV_URL=https://gitlab.com/joubu/koha-misc4dev.git
DEBUG_GIT_REPO_MISC4DEV_BRANCH=unimarc
Then start the koha container
When the misc4dev will start its job, the scripts will have the expected
data to continue.
Without this patch you will get
koha_1 | Not enough data in the database, library and/or patron category does not exist at /kohadevbox/misc4dev/create_superlibrarian.pl line 31.
And plenty of errors will follow.
Also, the sample data used in misc4dev will use CPL
(/kohadevbox/misc4dev/data/sql/unimarc/1812/after_22155/items.sql)
Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Saving was accidentally commented out in patches, this restores that
To test:
1 - Create a new macro
2 - Add some content
3 - Reload the macro, no content
4 - Apply patch
5 - Repeat
6 - Macro saves/loads correctly
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Borrowers Template Toolkit plugin contains method IsDebarred that can be directly called from Koha::Patron object.
Also in template circ/returns.tt, when patron is restricted and checkin was backdated, var "patron" is undefined, should be "issue.patron".
Test plan :
1) Enable system preference SpecifyReturnDate
2) For a patron without restriction create a checkout
3) Create a manual restriction to debarre patron
4) Go to return page and click on "Checkin settings"
5) Specify a date in the past, barcode and click "Check in"
6) You see message "Jon Doe is restricted. Please verify this patron should still be restricted."
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Borrowers Template Toolkit plugin contains method HasOverdues that can be directly called from Koha::Patron object.
Test plan :
1) Go to circulation page of a patron with overdues
2) Click on print button
3) You see "Print overdues"
4) Go to circulation page of a patron without overdues
5) Click on print button
6) You don't see "Print overdues"
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The MARC preview of staged records fails when a staged record contains
items with UTF-8 characters (see attached screenshots). That's because
in EmbedItemsInImportBiblio() the call to MARC::Record->new_from_xml()
does not explicitly specify 'UTF-8' as the optional encoding to use.
This patch fixes that.
Test plan (in a MARC21 instance):
0) Stage for import the test record attached to this bug report (make
sure that 'Check for embedded item record data?' is set to 'Yes'),
then go to Home > Tools > Manage staged MARC records and click on
the filename you've just staged.
1) In the 'Citation' column, click on the hyperlink to launch the MARC
preview -- notice how it fails to produce any output apart from the
modal heading.
2) Apply the patch, and restart Plack if necessary.
3) Re-launch the MARC preview: this time the output should include the
whole record, including the embedded item data in field 952.
4) Run the unit tests to ensure nothing was broken inadvertently:
$ prove t
$ prove xt
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch standardises the encoding name used in direct calls
to new_from_xml() to 'UTF-8' instead of 'utf8' or 'utf-8'.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch introduces code to detect (cookie) annonymous sessions and
act as expected.
Right now, as check_cookie_auth is not passed the required permissions
(because there aren't always required permissions, and the code to check
permissions is shared with other authentication mechanisms) it returns
'ok' and the session id. This use case was overlooked when this was
coded, and yeilds unexpected error codes (500) when the user logs out
and the annonymous session cookie is used to hit the API. The end result
doesn't pose any security issue (i.e. the resource access is rejected)
but the returned error code is not correct and should be fixed.
This patch verifies for an anonymous session (and avoids querying the
corresponding patron) and then verifies if there is an authorization
config on the route and if the patron object is defined.
To test:
1. Apply the tests patch
2. Run:
$ kshell
k$ prove t/db_dependent/api/v1/auth_authenticate_api_request.t
=> FAIL: Tests fail, 500 instead of the expected 401
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
5. Repeat the original 'steps to reproduce' from the bug report using
the browser
=> SUCCESS: Problem solved!
6. Sign off :-D
Sponsored-by: ByWater Solutions
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch introduces tests for the expected behaviour on API routes
that expect a logged in user, but the request is made with an anonymous
session cookie.
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/api/v1/auth_authenticate_api_request.t
=> FAIL: Tests fail because the situation is not handled correctly in
the code
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1 - Apply patches
2 - Confirm you can save, load, and run macros
3 - Confirm you have no choice of format
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
With the 20.05 team we introduced and expanded some roles. This patch
adds support for:
* removal of the release maintainer for development releases
* a list of documentation managers
* a list of packaging manager
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Removes an unnecessary variable declaration from Auth.t
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
A few additional cases were introduced since the original bug was
authored. This patch simply catches those cases and makes the same
change.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 14407 introduced a new system preference to allow limiting the
online self checkout system to an IP or IP Range. The function that
handles this is called in_ipset, which is the name of a linux tool. To
stop confusion, this patch renames the function to 'in_iprange', and the
variable 'ipset' within it to 'iprange'.
To test, follow the test plans outlined in Bug 14407 and confirm that
everything works as expected.
Sponsored-by: Catalyst IT
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch updates some markup and CSS so that the process of selecting
a club from search results during the hold process looks the same as
when selecting a patron: Club names should be links (like patron
names are) and the table row should have a hover color to help indicate
that it is clickable.
This patch also changes the markup of the Patrons/Clubs tabs a little
bit to make the information clearer: Superfluous Bootstrap-related tab
markup has been removed, and the patron and club search results have
been moved into their respective tab containers. This means that if you
search for a patron but then switch to the clubs tab the patron list
doesn't still display.
To test, apply the patch and rebuild the staff client CSS
(https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_client)
- You should have more than one patron club defined.
- Begin the process of placing a hold on a title.
- Test the process of searching for both patrons and clubs.
- In each case the name (patron or club) should be an active link.
- Hovering your mouse over the table rows should change the row
background to yellow.
- Clicking the other tab at this stage should hide the search results
from your last search.
- Whether you click the linked name or elsewhere in the table row
you should be correctly redirected to the next step in the holds
process.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
TO TEST:
- Apply patch
- mark your library closed today and tomorrow
- set ReservesMaxPickUpDelay to 1 day
- set ExcludeHolidaysFromMaxPickUpDelay to "Ignore the calendar"
- place hold, capture hold
- hold expiration date is set to tomorrow (doesn't skip closed days)
- Set ExcludeHolidaysFromMaxPickUpDelay to "Use the calendar"
- Place hold, capture hold
- hold expiration date is set to the day after tomorrow (skips closed days)
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The ability to claim an item "claim returned" is not there if the syspref is empty, however, the Claim Returned tab is stil present on the patrons detail page.
Test Plan:
1) Ensure ClaimReturnedLostValue is not set
2) Note the claims tabs on the circulation and patron details pages
3) Apply this patch
4) Refresh those pages
5) The claims tabs should be gone!
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch fixes the formatting of dates on the following pages:
- catalogue/MARCdetail.pl (staff)
- cataloguing/additem.pl (staff)
- opac-MARCdetail.pl (opac)
To test:
1) Ensure that the following fields are visible in the opac, intranet
and editor. You may need to edit the subfields in your default
bibliographic framework
952$d date accessioned
952$q date due/on loan
952$r date last seen
952$s date last borrowed
952$w replacement price date
Also ensure you have dateformat system preference set
2) Go to cataloguing/additem.pl for a biblio. Fill in the fields above
if required. Save
3) Remain on cataloguing/additem.pl. Notice the items table at the top
of the page, the dates are in the generic yyyy-mm-dd format
4) Go to catalogue/MARCdetail.pl for that biblio. Notice dates in wrong
format
5) View this biblio in the opac opac-MARCdetail.pl. Scroll to bottom to
items table. Notice dates in wrong format.
6) Apply patch, restart memcached and plack and refresh pages
7) Dates should now be formatted according to dateformat preference
8) Confirm that changing the preference changes the format of the dates
Sponsored-by: Catalyst IT
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This persists after bug 20948 - we can still display patron information even if this patron is not the one
who will receive the item upon checkin. The holds tab can give an overview of holds and information - I think
on the details page the only info we need is whether there might be a item level hold, not who it is for
To test:
1 - Place an item level hold for delivery at a branch not matching home branch of item
2 - Place a record level hold for delivery at homebranch of item placed on hold above
3 - Enable LocalHoldsPriority with 'pickup library' matches the item's 'home library'
4 - View the details for the page, it says the item has a hold for the patron with an item level hold
5 - Check in the item, the hold triggered is for the next available patron, ignore the hold
6 - Apply patch
7 - Check details page, 'There is an item-level hold (priority=1)' with no patron info
8 - Check in, next available hold is still the one triggered
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
IdRef link is displayed via XSLT.
There is a test of syspref with just if value is defined.
But in installer/data/mysql/sysprefs.sql you see this pref will be 0 by default, which is true in XPATH.
We should test that pref is 1.
Test plan :
1) Create a fresh UNIMARC database
2) You have pref IdRef disabled
3) Simulate a SUDOC record:
Fill a 7..$3 field with a ppn (032581270 for example).
Fill the 009 field with an integer
4) Go to the opac detail page of the record => You don't see IdRef link
5) Enable IdRef syspref
6) Go to the opac detail page of the record => You see IdRef link
7) Disable IdRef syspref
8) Go to the opac detail page of the record => You don't see IdRef link
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
- go to admin/categories.pl
- click Help, confirm it takes you to manual main page
- apply patch
- restart all
- click Help, confirm it takes you to patron categories in manual
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
