Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is getting messy. No idea how I tested the previous patches but it
was not working, the problem still persisted.
This patch is using the I18N TT plugin to make things easier and fix the
original problem.
Test plan:
Apply the patch
perl translate update fi-FI
Edit misc/translator/po/fi-FI-messages.po
Locate and translate "Check out"
61 #: koha-tmpl/intranet-tmpl/prog/en/modules/members/tables/members_results.tt:20
62 msgid "Check out"
63 msgstr "Laina"
Locate and transate "View"
182 #: koha-tmpl/intranet-tmpl/prog/en/modules/members/tables/members_results.tt:22
183 msgid "View"
184 msgstr "Nayta"
Apply the change to the fi-FI templates
perl translate install fi-FI
Now enable the fi-FI in the lang syspref, search for patron and confirm
that the result view is displayed correctly.
Note that the "Check out" and "View" strings are correctly translated
(when you hover the cardnumbers or patron's names)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Koha used to rely on Mail::Sendmail for sending emails. As an SMTP
client, the library would extract the from address from the Sender
header to pass along in the MAIL FROM: field of the SMTP protocol [1].
This was overlooked when we moved to Email::Stuffer/Email::Simple and
there's a different behavior as it expects the envelope to be passed and
falls back to extracting the 'From' header when said envelope is not
found [2].
This patchset re-introduces the behavior from Mail::Sendmail by
overriding the send_or_die method locally (in Koha::Email) and doing the
right thing.
Unless an explicit {from} parameter is passed, it extracts the MAIL FROM
envelope from the Sender header, as Mail::Sendmail did, and calls
$self->SUPER::send_or_die with the right parameters.
To test:
1. Apply the unit tests
2. Run:
$ kshell
k$ prove t/Koha/Email.t
=> FAIL: Sender is not handled correctly!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
The from parameter is correct!
No Sender header sent!
5. Sign off :-D
[1] https://metacpan.org/dist/Mail-Sendmail/source/lib/Mail/Sendmail.pm#L284
[2] https://metacpan.org/pod/Email::Sender::Manual::QuickStart#envelope-information
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
AMENDED (SHORTENED)
- my @headers = $self->email->header_str_pairs;
- foreach my $pair ( pairs @headers ) {
- my ( $header, $value ) = @$pair;
- $args->{from} = $value if $header eq 'Sender';
- }
-
- # Remove the Sender header
- $self->email->header_str_set('Sender');
+ $args->{from} = $self->email->header_str('Sender');
+ $self->email->header_str_set('Sender'); # remove Sender header
Tested with same results (scrambled domains):
From: noreply@mydevserver.com
Cc: marcel@email.nl
To: test@somewhere.nl
Reply-To: bieb@mydevserver.com
Return-Path: postmaster@mydevserver.com
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Fix typo in template: Newletter => Newsletter
Fix latest newsletter editor definition.. it's a has not an array.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It seems we stopped recording the newsletter editor as part of the team
for a while :(.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
1. Have OpacBrowseResults on.
2. Make search with many results.
3. Go to the record detail page
4. Click 'Browse results'
5. At the bottom of the container notice the stray "s".
6. apply patch
7. Try again, the "s" is gone!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1) Create a new notice, for example with Koha module "Patrons",
name/code TEST and message body "<strong>testing<strong>".
2) Create a new sql report, the query could be someting like:
SELECT "<number>" as `borrowernumber`, "to@example.com", as `email`, "from@example.com" as `from`;
where "<number>" is a valid borrowernumber.
3) Run patron_emailer.pl --report=<id> --notice=TEST --module=members -commit
where <id> is the report id.
4) Check the message_queue table that the content_type column has been
set to text/html; charset="UTF-8".
5) Ideally process the message queue and veriy that the sent email is displayed
as rendered html.
6) Run tests in t/db_dependent/Reports/Guided.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When using any unit besides postscript points, barcode positionning
doesn't work correctly. There is an error in the calculation: the unit
factor must be applied to the individual card part only and not to the
full page position.
This patch moves the unit part of the calculation to the right place.
To test :
1. Create a working patron card setup, using postscript points:
card template, layout and card batch. Use barcode and at least
one other element (text or images) in the layout.
=> Some tips for testing:
- activate guides for the layout
- use a template and a batch containing more than one card; the
displacement will be different for each card and depend on the
barcode position relative to the bottom left of the entire page.
2. Change units from postscript points to any other unit.
=> At least for the layout, but changing it in the template will
scale the page as well.
4. Export the card batch.
3. Note the guides are scaled to fit the new unit and the lower left
corner of text and images are still correctly placed relative to the
guides, but the barcode is not.
=> In some cases, the barcode even seem to not print at all since
it's new coordinates are out of screen.
4. Apply patch.
5. Generate the batch again.
6. Note the barcode now appears exactly where it should.
Signed-off-by: George Veranis <gveranis@dataly.gr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1. Make an item eligible for auto_renewal.
2. Set circ rule so only 1 auto_renewal is allowd.
3. Run auto_renew once, get a successful message.
4. Run it again and get the too_many error "You have reached the maximum number of checkouts possible."
5. This has nothing to do with the number of checkouts
6. Apply patch and updatedatabase.
7. Do 1-4 again.
8. Message is now "You have reached the maximum number of renewals possible."
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When placing a hold, the dropdowns for selecting a pickup library automatically right-truncate, so one can type "cen" and find Centerville.
On the Libraries page in Admin, however, the search box both left- and
right-truncates, so one can type "en" and find Centerville.
This patch makes the search perform 'contains' searches.
To test:
1. Try placing a hold. Make sure your rules allow Centerville to be a
valid pickup location.
2. Search 'cen'
=> SUCCESS: Centerville shows
3. Search 'en
=> FAIL: Centerville doesn't show
4. Apply this patch and reload
5. Repeat 2
=> SUCCESS: Works!
6. Repeat 3
=> SUCCSS: Centerville shows!
7. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes the select2 dropdowns for pickup locations not be
limited to the RESTdefaultPageSize syspref limit.
To test:
1. Have less than 20 libraries in your system as valid pickup locations
2. Place a hold via the staff client
=> SUCCESS: See that all your libraries appear in the pickup location dropdowns at the bib and item level
3. Update RESTdefaultPageSize, set the value to something lower than your count of pickup libraries
4. place another hold
=> FAIL: Your pickup location list gets cut off and only shows as many locations as RESTdefaultPageSize allows
5. Apply this patch
6. Repeat 4
=> SUCCESS: All your pickup locations show
7. Sign off :-D
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>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds an option to insert "Source of classification or
shelving scheme" as a runtime parameter in SQL reports. The ability to
use cn_source as a parameter seems to have always been part of this
feature but wasn't documented.
To test, apply the patch and go to Reports -> Create from SQL.
- Click the "Insert runtime parameter" button and select
"Classification source."
- Customize the parameter label if you wish and click "Insert
parameter."
- The parameter should be inserted like this:
<<Source of classification or shelving scheme|cn_source>>
- Use it to create a valid SQL report, for example:
SELECT * FROM items WHERE cn_source = <<Source of classification or
shelving scheme|cn_source>> LIMIT 10
- Confirm that upon running the report you are prompted to select a
classification source.
- Confirm that the report runs correctly.
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch alters the form shown when using the "Insert runtime
parameter" button in SQL reports. It makes the label field required and
removes "optional" from the field hint.
To test, apply the patch and go to Reports -> Create from SQL.
- Click the "Insert runtime parameter" button and select "Authorized
value."
- Clear the "parameter label" field and click "Insert parameter."
- The form should display an error asking you to fill in the label
field.
- Test that the category field is also required.
- Close the modal and select a different runtime parameter.
- Test again that the label field is required.
- Test that the form submits correctly when the label field is
populated.
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds an option to insert "list" as a runtime parameter in SQL
reports (As added by Bug 27380).
To test, apply the patch and go to Reports -> Create from SQL.
- Click the "Insert runtime parameter" button and select
"List."
- Customize the parameter label if you wish and click "Insert
parameter."
- The parameter should be inserted like this:
<<List of values|list>>
- Use it to create a valid SQL report, for example:
SELECT * FROM borrowers WHERE categorycode IN <<List of values|list>>
LIMIT 10
- Confirm that upon running the report you are shown a textarea. Enter
two or more values in the textarea, each on a separate line.
- Confirm that the report runs correctly. The SQL above would show you
this when you click "Show SQL code":
SELECT * FROM borrowers WHERE categorycode IN ('A','S') LIMIT 10
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a step to Flatpickr initialization to add an
autocomplete attribute set to "off" so that browsers' built-in
autocomplete menus do not obscure the calendar.
To test you must be using a browser which has form history enabled.
Locate a form that includes a Flatpickr input field, e.g. Reports
-> Catalog statistics.
Fill the date fields and submit the form. Go back to the form and click
one of the form fields you previously filled out (once in Chrome, twice
in Firefox). The browser should not show its native form history
dropdown.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes changes to the OPAC Cart's CSS and JS so that the cart
pop-up message display more consistently. The CSS is changed to use
position "fixed" instead of "absolute." This allows the message to
display without recalculating the position every time, and keeps the
appearance we expect.
The z-index of the message is also increase to prevent it from being
hidden behind a floating toolbar.
To test, apply the patch and rebuild the OPAC CSS
(https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_client).
- Perform a catalog search in the OPAC which will return multiple
results.
- In the list of search results, click the "Add to cart" link next to
several search results. Each time you should see a message appear in
the upper left corner of the screen, "The item has been added to the
cart."
- The position of the messages should be consistent no matter how far
down the page you scroll.
- Test again after adding content to the OpacHeader region. One way to
do this is to add the following to the OpacUserJS preference:
$(document).ready(function(){
$("#wrapper").prepend('<img src="https://generative-placeholders.glitch.me/image?width=900&height=200&style=triangles&gap=30">');
});
- Test at various browser widths, from a phone-sized screen width up to
wide desktop-sized.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch corrects eslint errors in the OPAC copy of basket.js:
Indentation inconsistencies, undeclared variables, unused functions,
etc.
To test, apply the patch and test the "Cart" functionality in the
OPAC:
- In the OPAC, add an item to the cart.
- A popup message should appear telling you the item has been added.
- The "Add to cart" link should update to read "In your cart."
- The count if cart items in the header should be updated.
- The "In your cart (remove)" link should work correctly.
- Test this process from both the search results and
detail pages.
- Open the cart.
- The cart should open correctly.
- In the cart, test all the controls:
- More details
- Send
- Download
- Empty and close
- Hide window
- Print
- Select all / clear all
- With checked items:
- Remove
- Add to list
- Place hold
- Tag
The following unused functions were removed: readCookieValue,
AllAreChecked, SelectAll, and quit. A search of the Koha codebase should
return no results from the opac-tmpl directory.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
to test...
- apply patch
- build package
- confirm in about.pl that minimum versions are updated
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1. Go to cataloging search and enter something like "7th Heaven".
2. Get an error when searching, Koha thinks you entered an ISBN
3. Apply patch
4. Try the same search, it should be a proper title search now
5. Find some stuff in the catalog with ISBN numbers in them.
6. The search should properly return ISBN13/ISBN10 searches, without with out the '-'.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In Administration › Libraries, we see content of OPAC info as escaped HTML.
This content may be long and seeing HTML tags is strange.
We should not show it in this table.
Or maybe create a modal preview of it (not escaped HTML).
To test :
1) Home > Administration > Libraries
2) In 'Address' column notice the 'OPAC info' field (if this one is
filled) with visible HTML tags
3) Apply patch
4) Repeat 1) and 'OPAC info' field should be gone
Signed-off-by: Owen <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - go to itemtype config in Admin
2 - confirm it doesn't mention the automatic_return cron
3 - apply patch and restart
4 - confirm note now says "This feature requires the misc/cronjobs/automatic_checkin.pl cronjob. Ask your system administrator to schedule it."
Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Set system preference AutoRenewalNotices to 'according to patron messaging preferences'
2 - Set circ rule for auto renewal - 100 renewals allowed - no renewal before 100
This shoud make a checkout eligible for many auto renewals for testing
3 - Checkout an item to a patron, ensure item is from a different branch than patron
4 - Ensure the patron has an email, and set an email for patron's branch and items branch
5 - Set the patron messaging preferences for auto-renewal to 'email' and 'wants digest'
6 - perl misc/cronjobs/automatic_renewals.pl --send-notices --confirm
7 - Job dies:
Can't call method "from_email_address" on an undefined value at /usr/share/koha/bin/cronjobs/automatic_renewals.pl line 286.
8 - Apply patch
9 - Repeat
10 - NO errors
11 - Check patron notices tab, should be a notice enqueued, check DB to see from address is patron's branch
12 - perl misc/cronjobs/automatic_renewals.pl --send-notices --confirm --digest-per-branch
13 - No errors
14 - Check patron notices tab, should be a notice enqueued, check DB to see from address is item's branch
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Behvaiour before this option was added was 'homebranch'
We should preserve this rather than introduce a change
No atomic update added as liobraries may have already set/changed the value,
but safer to default to previous behvaiour
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To try and clarify the logic here I've added an addition comment to the
code.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch prevents the call to set_time_zone if we are handling a
dateonly datetime string or a DST time
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds handling to ensure we always convert a passed in time to
the instance configured timezone..
Signed-off-by: David Cook <dcook@prosentient.com.au>
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: David Cook <dcook@prosentient.com.au>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We should die on invalidly formatted dates being passed. This patch
adds such a test case.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds correct handling for when an offset is passed within an
RFC3339 formatted datetime.
Test plan
1/ Run the DateUtils test and varify it now passes.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The tests were incorrectly passing for RFC3339 dates passed with an
offset. This patch corrects the test.
Test plan:
1/ Read the change
2/ Agree the change adheres to the RFC
3/ Run the test and varify it now fails
3/ Signoff
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We have already a search filter for active orders.
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When deleting a basket we cancel all the contained orders - when a
basket contains an order that was previously cancelled this can cause
an error if the biblio was deleted
When picking the orders to cancel, we should limit our search
to those not already cancelled.
To test:
- have a basket with at least one order
- click "Cancel order and delete catalog record", confirm cancellation of order and deletion of bib
- click "Delete basket", confirm deletion
- get error "Cannot insert order: Mandatory parameter biblionumber is missing at /kohadevbox/koha/acqui/basket.pl line 136.
at /usr/share/perl/5.28/Carp.pm line 289"
- apply patch
- restart
- delete the basket
- success!
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
SIP connections tend to be long lived, weeks if not months, in the
libraries I see. Basically the connection per SIP machine is initiated
once when the SIP machine boots and then never closed until
maintanance needs to be done. Therefore we need to reset the Koha's L1
caches on every SIP request to get the latest sysprefs and configs
from the memcached cache that is shared between all the Koha
programs (intranet, opac, sip, cronjobs) and is guaranteed to be up to
date.
To test:
0. Have kohadevbox
1. Enable IssueLog
2. In one terminal run the command "perl C4/SIP/SIPServer.pm /etc/koha/sites/kohadev/SIPconfig.xml"
3. Checkin and return a book using telnet:
$ telnet localhost 6001
9300CNterm1|COterm1|CPCPL|
11YN20211010 10565320211010 105653AOCPL|AA1|AB3999900000001|ACterm1|BON|BIN|
09N20211010 10564420211010 105644APCPL|AOCPL|AB3999900000001|ACterm1|BIN|
4. Keep the telnet connection open and go to
http://localhost:8081/cgi-bin/koha/tools/viewlog.pl and check that
the *checkout* entry is in the circulation rules 5.
6. Disable IssueLog
7. Move back to the telnet prompt and check out and return a book again
11YN20211010 10565320211010 105653AOCPL|AA1|AB3999900000001|ACterm1|BON|BIN|
09N20211010 10564420211010 105644APCPL|AOCPL|AB3999900000001|ACterm1|BIN|
8. Go check out the circulation logs and notice a new entry was added
when it shouldn't have according to the IssueLog syspref!
9. Apply patch and repeat steps to notice that the syspref is now
followed correctly.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We were shifting the price and replacement price for imported orders
only after the line:
> $duplinbatch = $import_batch_id and next if $duplifound;
This lead to the "replacementprice" and "price" query parameters not
being shifted/removed from the list if a duplicate record came across
and caused the prices be applied to the next record being imported.
To reproduce:
1) Download two records from koha to marcxml file, then cat those:
cat bib1.marcxml bib2.marcxml > bibs.marcxml
2) Delete bib2 from koha
3) Stage bibs.marcxml for import
4) Create a new order basket, then "Add to basket" using "From a
staged file" option
5) Select both bib1 and bib2 and set price & replacement price for
bib1 to be 99.00 and for bib2 to be 88.00
6) Click save and notice bib2 was imported with the wrong prices, 99.00!
7) Apply patch and notice the prices are now correctly set to 88.00.
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It looks like this problem was caused by code from bug 25033, we were attempting to have the
dropdown either be the current branch filter, or the suggestion's branch code, but the variables here are confusing and it didn't work
This explicitly sets the branchcode when creating a new suggestion to allow fixing current behaviour and
show the correct value when creating new
To test:
1 - Be signed in as branch A
2 - Browse to suggestions and limit to branch "Any"
3 - Click 'New suggestion"
4 - Defaults to Any
5 - Cancel and limit to branch B
6 - New suggestion defaults to branch B
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When editing a suggestion, the library will be reset to the currently
logged in librarian's homebranch, no matter what the libray was before.
This fixes this, the library selection will remain at the db value when
edited.
To test:
- Create a suggestion with Any library.
- Edit the suggestion - it will show your homebranch as library
- Change to any library but your homebranch
- The summary should show the correct value after saving
- Edit the suggestoin again - it's set back to your homebranch again
- Apply patch
- Repeat the steps, the pull down should now show the correct library
at all times.
Caveat: I think there is a somewhat separate issue/bug in that once a library
was saved, you cannot switch back to "Any". I haven't been able to fix this and
suggest to maybe file a separate bug.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When trying to replace an authority record with Z39.50/SRU then a new authority
record is created without deleting the old one and not link the new one with
any record.
This patch fixes that.
Test plan:
1) Try to catalogue a new authority record from cataloguing form.
2) Try to replace that authority record with Z39.50/SRU, then a new authority
record is created and also you have that one that you tried to replace.
3) Apply the patch.
4) Try to replace the authority from step1 with Z39.50/SRU, then is working as
expected.
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Eric Phetteplace <phette23@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
