Run t/db_dependent/Accounts.t
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 88db3b587e)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
See bug 22847. We should never call ->Get in this template, we want
to display the values in the DB, not the calculated ones
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit c4ca7bff68)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 4ad2bedb97)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Adds a missing semicolon to one of the lines with translated
messages.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 660a5b6ebc)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch makes a change to the subscription entry template as a
workaround to a translation bug which is causing JavaScript errors when
using translated templates.
To test, apply the patch and update and install the de-DE template:
> cd misc/translator
> perl translate update de-DE
> perl translate install de-DE
- Go to Administration -> System preferences and enable the "Deutsch
(de-DE)" language under I18N/L10N preferences -> language.
- Switch to the "Deutsch" translation.
- Go to Zeitschriften (Serials) -> Neues Abonnement (New subscription)
and open the browser console. There should be no errors.
- Links which trigger JavaScript events should work correctly:
"Lieferant suchen," "Nach Datensatz suchen," etc.
Reported-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Thanks-to: Michael Hoffert and Alexander Arlt from koha-de for reporting
it initially and figuring out the root of the issue
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 0dd2d6883d)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
It gives incomplete results and not sure it ever worked.
To prevent data loss it is better to remove this option.
Note that the code in C4/ImportExportFramework.pm is too complex to
attach with this patch to deletion of the code related to the XML
import/export. Safer to keep it for a separate bug report.
Test plan:
Import/export biblio frameworks and confirm that there is no more
reference to the xml format.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit ed45a4f333)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
There is not FK constraints on the itemtype, categorycode and branchcode
columns of the issuingrules table, because of the '*' value we use for
default.
We created the new table circulation_rules with those constraints, and
when we moved the rules for maxissueqty, the INSERT failed.
To avoid the FK constraints to fail we are going to delete the invalid
rows before.
It could lead to data lost, but this situation certainly comes from a
bad data manipulation at some point of the history of the installation.
Test plan:
git reset --hard 1e4f442442 # before 18.12.00.020
reset_all
insert into branches(branchcode, branchname) values('rmme', 'rmme');
insert into categories (categorycode, description) values ('rmme', 'rmme');
insert into itemtypes (itemtype, description) values('rmme', 'rmme');
Go to http://pro.kohadev.org/cgi-bin/koha/admin/smart-rules.pl
Create a new rule for the patron category
Create a new rule for the item type
Copy all the default rule to the new library
Create other rules for "Default checkout, hold policy by patron category" and "Default holds policy by item type" using this patron's category and itemtype.
Same for patrons' categories and itemtypes you will not delete.
delete from branches where branchcode="rmme";
delete from categories where categorycode="rmme";
delete from itemtypes where itemtype="rmme";
git checkout master
and execute the DB process.
=> With this patch applied you will not get the error and the rules will
be moved correctly.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit ff3d7b9f8e)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds a unit test to t/db_dependent/Illrequests.t, where
a new node without any next_actions or prev_actions is added to the
core status graph.
Running the tests show a lot of warnings about "no query in
themelanguage", but that should not be related to the current bug.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 291bb7bacf)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Minor correction to mislabled POD section for private method.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 2ceeebd524)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Isherwood <andrew.isherwood@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 6338001208)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
It seems that discarge notices never got support for truetype
fonts, so notices are missing non-latin characters.
Signed-off-by: Theodoros Theodoropoulos <theod@lib.auth.gr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit e909494ac9)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
A Perl boolean value is on the server side converted
to a JS string (resulting in the values '0' or '1).
Since the string '0' is a truthy value in JS this
incorrectly triggers window.close() on the client
in many instances, for example when adding a new item.
To test:
1. Go to a bibliographic record in the staff client.
2. Expand the "New" menu and open "New item" in new tab.
3. The new tab will immediately close.
4. Apply the patch.
5. Perform steps 1-2 again.
6. The tab should now remain open.
Sponsored-by: Gothenburg University Library
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>
(cherry picked from commit b488527ebe)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
To test:
1 - Check out to a patron
2 - Note the display under the checkotu box does not have title
3 - Apply patch
4 - Checkout another item
5 - Note the title displays
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit dfdf3a7445)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
marc_records_to_documents is now an arrayref of hashes, not an arrayref of arrays
_sanitise_records has been removed, we don't need those tests anymore
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit bc8b8a7a6b)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Elasticsearch indexing uses 999$c to store record id by deleting the all field first !
So you can not store anything in field 999, even in UNIMARC and even in authorities records.
Looks like it is quick fix code added to start Elasticsearch use.
This behavior is disturbing and very strange for UNIMARC flavour.
This patch corrects by defining record ids mandatory in Koha::SearchEngine::Elasticsearch::Indexer::update_index().
This ids array is actually always given (except in UT).
I think it is useless to allow adding a record without its id.
Test plan :
1) Use Elasticsearch as SearchEngine
2) Create a subfield 999$z in default framework
3) Create a record with default framework
4) Enter a random string (never used in catalog) like "tototata" in 999$z
5) In Search engine configuration, define search field "subject" for 999$z
6) Rebuild record : misc/search_tools/rebuild_elasticsearch.pl -b -bn <biblionumber> -v
7) Search for the random string => You get a result
8) Optionnaly look at records in ES : <es server>:9200/<es index name>/data/<biblionumber>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit fb083813a8)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 90e2882568)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
If a person is fetching all data, it seems most likely that that person wants
to see all the data in the chart. We should default to that behavior.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit afa1106782)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patchset prevents the full return of report data unless explicitly requested by the user for charting purposes
Additionally the user is warned if requesting more than 1000 rows of data
To test:
1 - Create a report that returns over 1000 rows of data
2 - Run the report
3 - Note you have two buttons now 'Chart data' and 'Fetch all data for chart'
4 - Click chart data
5 - Note the note that you are only charting visible data
6 - Create the chart and confirm it works
7 - Close the chart
8 - Click 'Fetch all data'
9 - Note the confirm window
10 - Click 'cancel', note there is no change
11 - Repeat and click ok
12 - Fetch all data button is gone
13 - Page to next data, note fetch all does not return
14 - Click 'Chart data'
15 - Note you now have checkbox option to use all data in report
16 - Click it
17 - Create chart
18 - Confirm it works as expected
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 83a545d831)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Updatedatabase, rev. 18.12.00.051
Solved by testing the value of the pref first.
Tested by copying the change in a new atomic update with XXX.
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: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 6d1b3cf212)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Whenever a fine (accountlines in DB) has a precision longer than two floating points, it becomes very hard for a user to clear it.
Ex: 1.035 will be displayed as 1.04 or 1.03 depending on the screen. But entering any of those value in Pay Fine will not clear it.
The user has no way to know the exact value to enter.
This fix makes sure that the intent of the user is met, by matching the EXACT needed sum when the difference is less than 0.01.
TEST
1) Create a 1.035 fine
- Go to a Patron screen
- Fines tab on the left
- Create manual invoice
2) go to Pay fines, click Pay amount on bottom left.
3) It will show 1.03 as Total, and as Collect from patron. Click confirm.
4) An error message will appear.
5) Apply patch, do again.
Signed-off-by: Hayley Mapley <hayleymapley@catalyst.net.nz>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit c2df905bfe)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch could be moved to its own bug report if we want to adjust
tests.
Sponsored-by: BULAC - http://www.bulac.fr/
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>
(cherry picked from commit 4274a2f51d)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
There are some weird behaviors happening when using the "Organize by:
library" dropdown along with the library filter (in the "Acquisition
information" box).
I am suggesting the following test plan:
0. Create several suggestion from different libraries
A. You are superlibrarian and IndependentBranches is not set (=No)
1. Hit /suggestion/suggestion.pl
=> Default view shows the suggestions from your library
2. Filter by another library
=> You see the suggestions from this library
3. Filter by "Any" libraries
=> You see all the suggestions
4. "Organize by library"
=> You see all the suggestions, organized by library
5. Filter by a specific library
=> You see the suggestion from your library, all in one tab
B. You are not superlibrarian and IndependentBranches is not set (=No)
Same as A.
C. You are superlibrarian and IndependentBranches is set
Same as A.
D. You are not superlibrarian and IndependentBranches is set
You will never see suggestions coming from outside your library
QA: To be clear: the whole script needs a rewrite, but here we are just
trying to fix weird behaviors.
Sponsored-by: BULAC - http://www.bulac.fr/
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>
(cherry picked from commit 9f16ab9e75)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Removing the default on changed_fields leads to the requirement for
tests to specify data to add to said field when mocking data.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 14e5d38773)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Installation under Ubuntu 18.04 is blocked:
install.pl: DBD::mysql::st execute failed: BLOB, TEXT, GEOMETRY or JSON
column 'changed_fields' can't have a default value at
/usr/local/share/perl5/DBIx/RunSQL.pm line 273.
https://dev.mysql.com/doc/refman/5.7/en/data-type-defaults.html
"""
The BLOB, TEXT, GEOMETRY, and JSON data types cannot be assigned a
default value.
"""
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 1d64b1b63d)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Without the patch, renewing from the renewal tab/page
led to wrong renewal/due dates.
To test:
- Check an item out to your patron account
- Renew it from the patron account
- Note the due date
- Return the item
- Check the item out again
- Renew it using the renewal tab
- Verify a different due date was calculated
- Apply patch
- Repeat test - due dates now should be the same
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit a24c17a2aa)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Test Plan:
1) Create a basket with a non-default value for aqbasket.create_items
2) Click Edit from basket.pl
3) Click Save without changing anything
4) Note that aqbasket.create_items is no longer set
5) Apply this patch
6) Restart all the things!
7) Repeat steps 1-3
8) Note create_items is unchanged!
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>
(cherry picked from commit 2f315139e2)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
On the suggestions management page (suggestion/suggestion.pl) you can
select suggestions and change their status.
But it only works for "ACCEPTED" or "REJECTED".
Maybe caused by bug 22905.
Test plan:
Select at least one suggestion on the screen and select the "Pending"
status.
=> The status of the selected suggestions must have been updated
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 030eb694a8)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
When replacing F and FU with 'OVERDUE' + status in bug 22521 I missed
the cases inside the maninvoice template. This patch should correct
that mistake.
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 9d33b82fe8)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds the missing `{ Slice => {} }` attribute to the database
call introduced in bug 23265 to fix the use of Koha::Objects introduced
originally in bug 12063.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit ea1f698669)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
While the code requires external auth to test, the change is simple enough I
think a good read would suffice
To test:
1 - You either need Shib or CAS enabled and setup
2 - Add two users with blank.null cardnumbers
3 - Lock those user accounts
Set failedloginattempts to 1
Try a bad login with the userid
Or set via the DB
4 - Try a good login via the external auth
5 - Note it fails
6 - Apply patch
7 - Login now succeeds
Signed-off-by: Mike Somers - Bridgewater State University <msomers@bridgew.edu>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit c9c6dd1016)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Run prove t/db_dependent/Koha/SearchEngine/Elasticsearch/QueryBuilder.t
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit ce8896f17d)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
During cataloguing of an existing biblio, on an heading field,
the use of tag editor fills authorities finder with existing value :
Search main heading ($a only)
Search main heading
Default operator beeing 'contains'.
Actually with Elasticsearch those search give no results.
Example with heading :
200
$a Casaubon
$b Isaac
$f 1559-1614
Call to Elasticsearch :
"query" : {
"bool" : {
"must" : [
{
"query_string" : {
"query" : "Casaubon*",
"default_field" : "heading-main",
}
},
{
"query_string" : {
"query" : "(Isaac*) AND (1559-1614*)",
"default_field" : "heading"
}
}
]
}
},
"sort" : [
{
"heading__sort.phrase" : "asc"
}
]
}
Patch adds to "query_string" :
analyze_wildcard : true.
Test plan :
1) Use Elasticsearch
2) Edit an existing biblio record
3) Use tag editor on a heading
4) Click search => You get correct results
5) Check also search in authorities-home.pl
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit a94e863c3e)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
When fixing Bug 23589 Theodoros Theodoropoulos noticed that we are sending
headers and html after pdf output to browser.
Using exit inside eval block doesn't stop plack from generating
headers and html page after exit since CGI::Compile will catch
exit but doesn't stop emiting output. Example is:
eval {
warn "in eval";
exit;
};
warn "after eval";
Under CGI, this would print just "in eval", but under plack we get both lines
and thus generate additional header and html after we already sent pdf data.
Signed-off-by: Theodoros Theodoropoulos <theod@lib.auth.gr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 43d999cc7c)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
In cataloging.js $(document).ready adds noEnterSubmit class.
This does not work in ajax context, it works with $(document).ajaxSuccess.
Test plan :
1)
1.1) Verify you have an item subfield linked to items.itemnotes, ie 952$z
1.2) Verify 952$z exists in ACQ framework
2)
2.1) Verify system preference "AcqCreateItem" is on "placing an order"
2.2) Go to an acquisition basket
2.3) Click "Add to basket" and "From a new (empty) record"
2.4) Go to "Item" block
2.5) Verify that $z has "noEnterSubmit" class
2.6) Verify that typing enter in $z does not submit the form
3)
3.1) Change system preference "AcqCreateItem" to "receiving an order"
3.2) Go to "Receive shipment"
3.3) Receive an order
3.4) Go to "Item" block
3.5) Verify that $z has "noEnterSubmit" class
3.6) Verify that typing enter in $z does not submit the form
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit c66cebf744)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
In serials receive and acquisition order creation from iso2709, the item edition form shows inputs that are missing "input_marceditor" class.
They are also missing tabindex and id.
The side effect is that those inputs dont get the "noEnterSubmit" class so form is posted if a barcode scanner is used or if enter is used on keyboard.
Test plan :
1)
1.1) Verify you have an item subfield linked to items.itemnotes, ie 952$z
1.2) Verify system preference "AcqCreateItem" is on "placing an order"
2)
2.2) Go to cataloguing module and edit an item
2.3) Verify that $z has an id, tabindex and "input_marceditor" class.
2.4) Verify that typing enter in $z does not submit the form
3)
3.1) Go to a serial with items creation, click on receive
3.2) Change status to "Arrived"
3.3) Verify that $z has an id, tabindex and "input_marceditor" class.
3.4) Verify that typing enter in $z does not submit the form
4)
4.1) Go to an acquisition basket
4.2) Click "Add to basket" and "From a staged file"
4.3) Click "Add orders" on a staged file
4.4) Go in tab "Item information"
4.5) Verify that $z has an id, tabindex and "input_marceditor" class.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit c855b1ca28)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit b63b55cda7)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 95a2ffc542)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
We should use build_sample item (from bug 21971) to create items,
otherwise we may not have a valid biblioitem and/or MARC record.
Test plan:
Set SearchEngine to ES
prove that the tests in Circulation.t now pass
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit 18f9ed465d)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
When the user doesn't have superlibrarian, full acq or
contracts_manage permission, don't show buttons for editing
and deleting contracts.
To test:
- Create a vendor with a few contracts
- Create a staff user with
- superlibrarian = can view edit/delete contracts
- full acq perms = same
- without manage_contracts = can view, but action buttons are gone
- Make sure the sorting of the contracts table works in all cases
Signed-off-by: Holly Cooper <hc@interleaf.ie>
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit d0a06e365b)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>