This patch adds a test to check the unicity of auth cats, simplify
the GetBudgetAuthCats subroutine and make it return an arrayref of scalar
instead of an arrayref of hashref with only 1 key.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When displaying a budget, the Planning button in the admin toolbar displays
Plan by months
Plan by libraries
Plan by item types
Plan by
The last one is empty, due to C4::Budgets::GetBudgetAuthCats returning an empty field if the budget has no sort defined.
This prevents returning an array with empty element(s)
TEST:
1) Admin -> Budgets
2) Select a budget
a) you must have '' (empty) in your aqbudgets.sort1_authcat field.
b) edit the budget (direct DB or interface) to get that.
3) Click on Planning dropdown, see the "Plan by <nothing> " entry.
4) apply the patch, revalidate.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No more empty option
No errors
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
[1] Remove a vim inserted i from XSLT.pm: IdRefi => IdRef.
[2] The comment about UNIMARC is somewhat confusing. Rephrased it.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Add option show or no inactive budget and more options
Use subroutine GetBudgetHierarchy for return all budgets
Delete subroutine GetBudgetPeriodDescription and theire tests
Use Price TT plugin
Correct name of column and capitalization the first letter
Add checkbox for show inactive budgets, default the drop down list containt a active budget
Not use [i] for inactive budgets, i add (inactive) at the end of inactive budget
Add vendor note in the list of show attribute
Test case:
Go to Home > Reports > Orders by fund
Select one or all budgets
You can show the inactive budget, default the drop down list containt a active budget
Choose output to screen ou csv file
Works as expected. QA tools OK with Bug 16104 applied.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
- changed 'Fund (budget):' back to 'Fund:', as the budget
no longer shows in the pull down.
- Fixed number of tests in Budgets.t
- Removed &GetBudgetPeriodDescription
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch allows the high holds loan length decrease to be overridden
either by a checkbox that remembers its setting during a series of
checkouts, or by a one time use override checkbox that will show
in the warning popup if a checkout is affected by high holds.
Test Plan:
1) Set up a checkout that will be affected by decreaseLoanHighHolds
2) Attempt to check out an item
3) Check the override checkbox
4) Note the checkout date is not reduced
5) Return the item
6) Start a new checkout for the patron
7) Check the "Don't decrease lean length based on holds" checkbox
8) Check out the item
9) Note you are not warned about the high holds decrease
and that the checkout length is not reduced
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This enhancment allows a library to prevent patrons from checking out
items if his or her guarantees own too much.
Test Plan:
1) Apply this patch
2) Find or create a patron with a guarantor
3) Add a fine to the patron's account
4) Set the new system preference NoIssuesChargeGuarantees to be less
than the amount owed by the patron
4) Attempt to check out an item to the guarantor, you will either
be warned or prevented from checking out based on your system
settings.
Signed-off-by: Cathi Wiggin <CWIGGINS@arcadiaca.gov>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Some libraries would like to prevent patrons from placing holds on
items where there are other items available for the patron to
check out.
Test Plan:
1) Apply this patch
2) Browse to the circulation rules
3) Note the new option for "On shelf holds allowed"
4) Set the rule to "If all unavailable", set "item level holds" to allow
5) Find a patron/branch/itemtype applicable to this rule
6) Ensure at least one item on the record is available for the
patron to check out
7) Attempt to place a hold for the item
8) Note you cannot place the hold
9) Check the available item out to another patron
10) Note you can now place a hold for the first patron
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Works as intended!
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Adding reserves.itemtype made a query to fail in CanItemBeReserved.
This patch prefixes the column names with the corresponding table names
to prevent that.
You can trigger the error by running
prove t/db_dependent/Holds.t
You should see something like this:
Column 'itemtype' in where clause is ambiguous
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Some libraries would like the ability to select the itemtype to request
when placing holds. For example, if a record has 3 copies of BookA and 3
copies of BookA in large print, this feature would allow a person to
place a hold on the record, but still be able to target only the Large
Print edition so that the first Large Print copy that becomes available
is targeted, rather than forcing the patron to select a particular copy
to hold.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Create a record with items of two or more itemtypes
4) Place a record level hold on the record while choosing one particular
itemtype
5) Check in an item from the record that is not of that itemtype
6) Notee it is not trapped for the hold
7) Check in an item from the record that does match the selected itemtype
8) Note the item is trapped for the hold
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Some libraries would like to be able to limit hold filling to items that
match the pickup library for a hold based on the item's home or holding
library. The patron's home library should not affect whether a patron
can place the hold, instead the hold will only be fillable when an item
matching the pickup location becomes available.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Note the new "Hold pickup library match" rules for "checkout, hold,
and return policy" and for "holds policy by item type"
4) Set the policy to "item's holding library"
5) Place a hold where the item's holding branch does not match
the pickup branch
6) Check in the item
7) Note it is not trapped for the hold
8) Update the item's holding branch to match the pickup branch
8) Check in the item
9) Note the item is trapped for the hold
10) Repeat steps 4-9 but for home branch instead
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as described
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
This patch removes the mysqlism (see comment #18)
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Fixed QA tools complaints about missing lines before
and after =cut in POD.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
To reproduce issue:
See comment #1
To test:
- Apply patch
- Leave syspref StatisticsFields empty
- Display statistics for an author
=> Result: Table displays Shelving location, Collection code, Item type
(as before)
- Change syspref to any combination of location|itype|ccode
=> Result: Table displays columns as appropriate
- Change syspref to some garbage
=> Result: Same as with empty syspref (was crashing without patch)
- Change syspref to valid combination with trailing |
=> Result: Table displays columns as appropriate (was crashing
without patch)
- Change syspref to a combination of valid and invalid fields
(location|blah|ccode)
=> Result: Table displays column of valid fields only (was crashing
without patch)
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Overdues.pm line 588 tries to do an $accountline->set with column outstanding
instead of amountoutstanding.
This patch fixes it.
To test:
- Verify that code change is correct.
- Try to trigger a situation where an existing fine is updated
(see comment in line 574 in C4/Overdues.pm)
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This patch does the same as the previous one, but affects lines which
have not been caught by the regex.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
The zebraqueue table should still be populated with updates if ES is enabled, so
the Zebra indexer keeps the Z39.50/SRU indexes up to date.
To test:
- Set SearchEngine = Elasticsearch
- Watch for zebraqueue changes
$ watch -n 0.5 'echo "SELECT COUNT(*) FROM zebraqueue WHERE done=0" | sudo koha-mysql kohadev'
- Call touch_all_biblios.pl to simulate record changes
$ sudo koha-shell kohadev ; cd kohaclone
$ perl misc/maintenance/touch_all_biblios.pl -v
=> FAIL: Notice the watch is not changing the number of records to be indexed.
- Apply the patch
- Call touch_all_biblios.pl to simulate record changes
$ sudo koha-shell kohadev ; cd kohaclone
$ perl misc/maintenance/touch_all_biblios.pl -v
=> SUCCESS: The count raises (more than 0) and the zebra indexer picks the updates.
- Sign off
Signed-off-by: Chris <chrisc@catalyst.net.nz>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
By default ES returns the facet terms ordered by most used, which makes
sense.
This patch removes resort done in the scripts (catalogue/search.pl and
opac/opac-search.pl) and moves it to the module.
For Zebra it's now done in C4::Search::getRecords, and there is no
change to expect (still alphabetically).
On the Elastic search side, we could imagine to let the library define
the order of the facets. The facet terms are now sorted by most used.
To test easily this change, turn on the displayFacetCount pref.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This reverts commit cd4905c2969b067476881016d0b03271f0bcc7c8.
This commit caused an error in C4::Search::GetFacets when running in
zebra mode.
Conflicts:
Koha/SearchEngine/Elasticsearch/Search.pm
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
By default ES returns the facet terms ordered by most used, which makes
sense.
This patch removes resort done in the scripts (catalogue/search.pl and
opac/opac-search.pl) and moves it to the module.
For Zebra it's now done in C4::Search::getRecords, and there is no
change to expect (still alphabetically).
On the Elastic search side, we could imagine to let the library define
the order of the facets. The facet terms are now sorted by most used.
To test easily this change, turn on the displayFacetCount pref.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
When creating a patron attribute type, there is a "Allow password"
checkbox. If checked, the librarian will be able to enter a password for
this patron attribute when editing a patron.
The goal was to allow a patron to log in with a secondary password.
However, this feature has never been implemented.
"""
commit 6fc62bcd32
CommitDate: Mon May 12 09:03:00 2008 -0500
extended patron attributes tables & syspref (DB rev 081)
- password_allowed (if set, staff patron editor will
allow a password to be associated with a value; this
is mostly a hook for functionality to be implemented
in the future.
"""
To decrease maintainability, this patch suggest to remove the 2 DB fields
borrower_attributes.password and
borrower_attribute_types.password_allowed
If they have not used by the library.
Test plan:
- Edit a patron attribute type and select "allow password"
- Edit a patron and defined a password for this attribute
- Execute the DB entry
- Note that you get a warning
- Empty the password field
- Execute the DB entry
- You do not get the warning and the 2 DB fields have been removed
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Currently if not logged in when browsing to
http://YOURCATALOG/cgi-bin/koha/sco/sco-main.pl
You are redirected to opac-auth.tt and SCOUserCSS and SCOUserJS are not
loaded. This page passes through a parameter to the template to indicate
this is an SCO login and appropriate CSS and JS should be loaded.
Additionally this patch ensure that when loggin in using the form you
are redirected to the sco-main.pl instead of the patron account page for
the user.
To test:
1 - Verify that normal login works on both staff and opac
2 - Verify that SCO link goes to login page if AutoSelfCheckAllowed is
set to "Don't allow"
3 - Enter changes into SCOUserJS and SCOUserCSS and observe these are
present on SCO log in page with AutoSelfCheck disabled
4 - Verify that a logged in opac user without permissions cannot access
the self-checkout module
5 - Verify that AutoSelfCheckAllowed and associated system preferences
function as expected
6 - Verify the AutoSelfCheck user is logged out if they attempt to visit
another page
Followed test plan.
If I go to http://YOURCATALOG/cgi-bin/koha/sco/sco-main.pl, CSS and JS trigger already on
the login form, I suppose that is intended.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
The default patron search types has changed from 'contain' to
start_with. Users consider it as a bug.
This patch revert the previous changes to default on 'contain'.
Test plan:
Search for patrons in different places (guarantor, checkout, patron
module, acquisition module, etc.) and confirm that the default is always
'contain'
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
GetLoanLength arbitrary defaulted to 21. The expected behavior seems to
be to default on 0 (loan will be dued today).
IMPORTANT NOTE: This patch will introduce a change in the behaviors for
configuration with a 0 in issuelength. Before this patch, the rule with
a issuelength==0 was skipped, now it's used!
Test plan:
1/ Do not define any rule: the due date will be today (before this patch
was +21 days)
2/ Define some rules which does not match the patron category, itemtype
or branchcode: the due date will be today (before this patch was +21
days).
3/ Modify a rule to match the checkout and set issuelength=0: the due
date will be today (before this patch, the rule was skipped)
4/ Modify this rule and set the issuelength to something > 0: the due
date will be adjusted (same behavior as before this patch)
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Works ok, checked 1-4
All test pass
No koha-qa errors
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The login page should not be displayed if the page is displayed in a
frame.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
Added the following indexes:
Interest-age-level | 591$a ind1=1
Interest-grade-level | 591$a ind1=2
lexile-number | 591$a ind1=8
Reading-grade-level | 591$a ind1=0
Moved 'lex' from a zebra index to a ccl alias to lexile-number.
Changed the handling of st-numeric in C4/Search.pm to allow for search ranges.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
This patch alters the MySQL query to remove a max statement which
incorrectly groups full annual barcodes with numeric values.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
From C4::Koha::GetAuthorisedValues
# TODO: the "selected" feature should be replaced by a utility function
# somewhere else, it doesn't belong in here. For starters it makes
# caching much more complicated. Or just let the UI logic handle it, it's
# what it's for.
Indeed, it's not a job for a subroutine, the template should take care of that.
Note that a perf gain could be won with this patch \o/
Test plan:
- Edit an itemtype and check the value of the "Search category" dropdown list
- Edit a patron attribute type and check the value of the "Class" dropdown list
- Detail for a catalogue record, the Status column should be correctly
populated if items are damaged and/or lost
- Item details for a catalogue record, the lost, damaged and withdrawn
value should be correctly displayed
- Edit a patron, the "street type" should be correctly selected
- Create a patron attribute type linked to an authorised value list.
- Edit a patron, set a value for this attribute, edit it again. The
correct value should be selected.
- Search for subscriptions. The 'Location' dropdown list should behave
correctly (select the entry you have choosen before, etc.)
- Edit a subscription, the location dropdown list should select the
correct value.
- Edit and view a suggestion with a 'reason for suggestion' set (you
should have at least 1 OPAC_SUG AV defined)
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>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
subroutines should not take $dbh in parameter.
C4::Biblio::TransformMarcToKoha has it and does not use it.
Test plan:
Look at the patch and confirm that all occurrences of
TransformMarcToKoha have been modified.
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Right now, ->dbh calls are actually quite expensive (they involve
DB connection health checks, each and every time). Some speed-sensitive
subroutines inside C4/Biblio.pm (GetMarcStructure, GetAuthorisedValueDesc)
have this statement
my $dbh = C4::Context->dbh;
on top of the code, but they don't always/don't usually need DB
handle - not at that stage at least. This trivial patch eliminates
unneeded ->dbh calls in those subroutines. With it, average
GetMarcStructure() running time goes down from 14 miliseconds
to 9 miliseconds (on top of Bug 16166), it also makes catalogue
search profiling a bit easier.
Test plan:
1) apply patch
2) ensure that catalogue searches are still working
3) run t/*Biblio* tests
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This subroutine always returns what has been sent in parameter.
It is unecessary and can be removed.
Test plan:
prove t/Ris.t
should not be noisy
Export a catalogue record in Ris should generate the same file with and
without this patch
NOTE: With/Without were identical in my testing.
t/Ris.t is nicely silenced.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
TEST PLAN
---------
1) prove t/Ris.t
-- very noisy
2) apply patch
3) prove t/Ris.t
-- just one confusing noise.
4) run koha qa test tools
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Add support for processing incoming Edifact Quotes, Invoices
and order responses and generating and transmission of
Edifact Orders.
Basic workflow is that an incoming quote generates an aquisition
basket in Koha, with each line corresponding to an order record
The user can then generate an edifact order from this (or another)
basket, which is transferred to the vendor's site
The supplier generates an invoice on despatch and this will
result in corresponding invoices being generated in Koha
The orderlines on the invoice are receipted automatically.
We also support order response messages. This may include
simple order acknowledgements, supplier reports/amendments
on availability. Cancellation messages cause the koha order
to be cancelled, other messages are recorded against the order
Which messages are to be supported/processed is specifiable on a
vendor by vendor basis via the admin screens
You can also specify auto order i.e. to generate orders from quotes
without user intervention - This reflects existing
workflows where most work is done on the suppliers website
then generating a dummy quote
Received messages are stored in the edifact_messages table
and the original can be viewed via the online
Database changes are in installer/data/mysql/atomicchanges/edifact.sql
Note new perl dependencies:
Net::SFTP:Foreign
Text::Unidecode
Signed-off-by: Paul Johnson <p.johnson@staffs.ac.uk>
Signed-off-by: Sally Healey <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Rename not_borrowered_since to not_borrowed_since
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
This patch adds the ability to select a patron list for deletetion
when using the Batch patron deletion/anonymization tool. It also adds
buttons to the the patron lists table to access both the batch deletion
and batch modification directly from the lists view.
This is a squash of previous patches but now adds a patron_list_id
parameter to C4::Members::GetBorrowersToExpunge and uses that routine to
fetch patrons from a list.
Test Plan:
1) Apply this patch
2) Create a list of patrons with the new Patron Lists feature
3) Try using the batch edit link form the lists table
4) Try using the batch delete link from the lists table
5) Verify previous functionality has not changed
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Patron batches are correctly passed to the edit and delete pages.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Test Plan (remains the same):
0) Back up your database
1) Apply all these patches
2) In your mysql client use your Koha database and execute:
> DELETE FROM systempreferences;
> SOURCE ~/kohaclone/installer/data/mysql/sysprefs.sql;
-- Should be no errors.
> SELECT * FROM systempreferences LIKE 'GoogleO%';
-- Should see 4 entries.
> QUIT;
3) Restore your database
4) Run ./installer/data/mysql/updatedatabase.pl;
5) In your mysql client use your Koha database and execute:
> SELECT * FROM systempreferences LIKE 'GoogleO%';
-- Should see the same 4 entries.
6) Log into the staff client
7) Home -> Koha administration -> Global system preferences
8) -> OPAC
-- make sure your OPACBaseURL is set (e.g. https://opac.koha.ca)
9) -> Administration
-- There should be a 'Google OAuth2' section with the ability
to set those 4 system preferences.
10) In a new tab, go to https://console.developers.google.com/project
11) Click 'Create Project'
12) Type in a project name that won't freak users out, like your
library name (e.g. South Pole Library).
13) Click the 'Create' button.
14) Click the 'APIs & auth' in the left frame.
15) Click 'Credentials'
16) Click 'Create new Client ID'
17) Select 'Web application' and click 'Configure consent screen'.
18) Select the Email Address.
19) Put it a meaningful string into the Product Name
(e.g. South Pole Library Authentication)
20) Fill in the other fields as desired (or not)
21) Click 'Save'
22) Change the 'AUTHORIZED JAVASCRIPT ORIGINS' to your OPACBaseURL.
(http://library.yourDNS.org)
23) Change the 'AUTHORIZED REDIRECT URIS' to point to the new
googleoauth2 script
(http://library.yourDNS.org/cgi-bin/koha/svc/auth/googleopenidconnect)
24) Click 'Create Client ID'
25) Copy and paste the 'CLIENT ID' into the GoogleOAuth2ClientID
system preference.
26) Copy and paste the 'CLIENT SECRET' into the GoogleOAuth2ClientSecret
system preference.
27) Change the GoogleOpenIDConnect preference to 'Use'.
28) Click 'Save all Administration preferences'
29) In the OPAC, click 'Log in to your account'.
-- You should get a confirmation request, if you are
already logged in, OR a login screen if you are not.
-- You need to have the primary email address set to one
authenticated by Google in order to log in.
30) Run koha qa test tools
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
To test
1/ Apply both patches
2/ This patch lets you easily configure mappings for categorycode values.
These mapping will be used when updating the user's account after a successful LDAP login.
Here is an example configuration :
<config>
<ldapserver id="ldapserver>
<mapping>
<categorycode is="usertype">STU</categorycode>
...
</mapping>
<categorycode_mapping>
<categorycode value="STU">STUDENT</categorycode>
<categorycode value="EMP">EMPLOYEE</categorycode>
</categorycode_mapping>
</ldapserver>
</config>
3/ With this configuration, LDAP users with the usertype value "EMP" on the LDAP server should have the "EMPLOYEE" categorycode in Koha.
Signed-off-by: Chris <chris@bigballofwax.co.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
To test
1/ Apply both patches
2/ This patch lets you easily configure mappings for categorycode values.
These mapping will be used when updating the user's account after a successful LDAP login.
Here is an example configuration :
<config>
<ldapserver id="ldapserver>
<mapping>
<categorycode is="usertype">STU</categorycode>
...
</mapping>
<categorycode_mapping>
<categorycode value="STU">STUDENT</categorycode>
<categorycode value="EMP">EMPLOYEE</categorycode>
</categorycode_mapping>
</ldapserver>
</config>
3/ With this configuration, LDAP users with the usertype value "EMP" on the LDAP server should have the "EMPLOYEE" categorycode in Koha.
Signed-off-by: Chris <chris@bigballofwax.co.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
These prefs do not need to be cached, a quick access to $ENV permit to
get the value.
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
Also fixes ! and +
Rebased to master
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
It makes perfect sense and works as expected. This part of the code is too
under-tested so no point requiring a regression test for such a simple change.
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
This failure has been introduced by
commit 243b797dd1
Bug 15285: Update common files
This is because the cannot_be_modified key is not always created by
C4::Utils::DataTables::ColumnsSettings subroutines
Test plan:
prove t/db_dependent/ColumnsSettings.t
should return green
And you can also test a table where the feature is set and a column
cannot be modified from the admin page.
NOTE: Works as described. I was pondering this potential
solution when I found it in bugzilla.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
