No matter what the selection of OPACShowHoldQueueDetails is, if it is
enabled it displays a line "Holds and priority:" even if you've opted to
hide one of those!
Test Plan:
1) Apply this patch
2) Test each setting of OPACShowHoldQueueDetails
3) Ensure each setting displays the correct fields ( or lack thereof )
Signed-off-by: Christopher Brannon <cbrannon@debian.localdomain>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Imagine this scenario: we have one record with four items. Two of those
items are checked out, one of those items is a waiting hold, and one of
those items is available. We would expect to see this on the search
results page. Instead, we will see both non-checked out items as
unavailable due to waiting holds.
This is due to a semantic issue GetReserveStatus.
C4::Search::searchResults uses GetReserveStatus to get the reserve
status of each item, but unlike all other calls to the sub, this one
passes in not only itemnumber, but biblionumber.
When no reserve is found for the available item, the subroutine uses the
biblionumber to grab what is essentially an arbitrary reserve to use for
the status. This makes no sense and this functionality should be
entirely removed from the subroutine so regressions like this will be
prevented in the future.
Test Plan:
1) Create one record with 4 items
a) check two of the items out to patrons
b) set one of the items as a waiting hold
c) leave the fourth item as available
2) Run a search where this record will be in the results list
3) Note that the results list 2 items on loan, two unavailable
4) Apply this patch, reload the search results
5) Note that the results list 1 available, 2 on loan, 1 unavailable
Signed-off-by: John Andrews <jandrews@washoecounty.us>
Signed-off-by: Sheila Kearns <sheila.kearns@state.vt.us>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Note: This is for the staff search result list!
Works as expected.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
1) Removed 'use C4::Context;' because it can lead to introduction
of circular reference in the near future
2) Put fastmmap initialization code into an eval {} block, to catch
various kinds of errors which can still occur during it's init in
some [less usual] Koha setups and/or more unusual circumstances
3) Do not include UID in the sharefile name (it will be constructed
using namespace + database name + database host instead).
Test plan addendum:
s/and UID//
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Koha::Cache package does not take into account that, when using
fastmmap caching variant, mmaped cache file created in /tmp
(typically: /tmp/sharefile-koha-koha), would only be further
accessible to the one given OS user - the one which created it.
In many Koha setups, in the circumstances when various system scripts
are executed by 2+ users with diffrent UIDs (like multi-tenant servers,
for example) this may cause many kinds of issues. Observable symptom
is usually the appearance of the below error when searching, or looking
at MARC Framework pages and a few other places:
Open of share file /tmp/sharefile-koha-koha failed: Permission denied
at /usr/lib/perl5/Cache/FastMmap.pm line 640.
This patch:
- disables initialisation of fastmmap caching subsystem unless it is
explicitly requested by the user (CACHING_SYSTEM=fastmmap)
- disables fastmmap cache usage for command line scripts
(i.e. when GATEWAY_INTERFACE environment variable is not defined)
- adds the database name, host name and an ID of the OS user to the
mmaped file name created in /tmp, to prevent various kinds of
unintentional conflicts and/or permission problems from happening
To test:
1) remove the /tmp/sharefile-koha-* file[s] (if any)
2) do something which would lead to its re-creation (e.g., performing
any search in OPAC should be sufficient to cause that)
3) observe that /tmp/sharefile-koha-koha got created
4) remove it
5) apply patch
6) redo step 2)
7) observe that aforementioned file is no longer created in /tmp
8) set CACHING_SYSTEM environment variable to 'fastmmap'
9) redo step 2), observe that /tmp/sharefile-koha-* file got created
and that it's name now contains hostname, database name and UID
10) ensure that everything still works like it should and that there
are no regressions of any kinds anywhere in the system ;)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
my $bar;
my $foo = $bar->{borrowernumber} ||= {};
$foo->{one} ||= 'something';
$foo->{two}++;
What does $bar contain?
$VAR1 = {
'borrowernumber' => {
'two' => 1,
'bar' => 'something'
}
};
Not really obvious.
Maybe something I did not see is hidden.
Test plan:
Verify the digest for DUE and PREDUE work as before.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If a link to a patron record ends with #reserves, the holds tab is selected
on page load, but the holds table does not load.
Test Plan:
1) Build your holds queue
2) From the holds queue report, open any patron link
3) Note the patron's reserves do not load
4) Apply this patch
5) Clear your browser cache
6) Repeat step 2
7) Note the holds table now loads
Signed-off-by: Sean McGarvey <seanm@pascolibraries.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The tests highligh the problem: if the parent_ordernumber attribute is
not set on inserting an order, the object returned by the method does
not contain the value (undef).
Test plan:
Verify the tests are consistent and
prove t/db_dependent/Acquisition/CancelReceipt.t
should return green.
You can also verify that receive partially an order and cancel the
receipt work as expected.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The acquisitions search is exhibiting the same behavior as bug 11410.
Results are always fixed in order of biblionumber, among other possible
issues ( including the ampersand issue ).
Test Plan:
1) From an open basket, choose "Add to basket"
2) Run a search for "From an existing record"
3) Note the "View MARC" URLs are fixed in order of biblionumber
4) Apply this patch
5) Refresh the page
6) Note the results are no longer fixed in order of biblionumber
Signed-off-by: David Cook <dcook@prosentient.com.au>
Works as described.
I think the code could be a bit tidier, but I think it makes sense to
use buildQuery here. It'll detect CCL, CQL, and PQF queries, as well
as parsing a regular keyword search as one would expect when searching
the catalogue.
It also has the added bonus of performing relevance searching,
so long as QueryAutoTruncation is off, and so long as library staff
avoid using the "*" truncation wildcard (see bug 12430).
While there are simpler ways to fix this acq bug, I think this was
probably the best move, as it adds a bit to the consistency of what
librarians can expect from their search results.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Same result with and without the patch but I agree with the changes.
BuildQuery should be called before SimpleSearch if QP is not used.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
C4::Acquisition::ModReceiveOrder updates the aqorders with
budget_id=NULL if no budget_id given in parameter.
Actually the same budget_id should be used.
In tests (especially t/db_dependent/Acquisition/TransferOrder.t),
ModReceiveOrder is not called with a budget_id param and set to NULL the
budget_id value.
test plan:
prove t/db_dependent/Acquisition/TransferOrder.t
should return green
Note that this bug should not appear using the interface.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The fix makes sense, and running
$ prove t/db_dependent/Acq*
returns all green. koha-qa.pl also likes it.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Booksellers.t and Koha_template_plugin_Branches.t both had
function calls to ::set_userenv added to them. This patch handles
those additions.
TEST PLAN
---------
1) Branch a new git branch
2) prove -v t/db_dependent/Bookseller.t
-- It should work.
3) prove -v t/db_dependent/Koha_template_plugin_Branches.t
-- It should work.
4) Apply only the first patch.
5) Repeat steps 2 and 3.
-- They should both FAIL!
6) Apply the second patch as well.
7) Repeat steps 2 and 3.
-- The should both work.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
There were multiple calling conventions for C4::Context's
set_userenv routine. So the following commands were used to
find discrepancies:
grep "::set_userenv" `find .`
grep "\->set_userenv" `find .`
The first grep demonstrated that the smaller change is from
:: to -> as only C4/Auth.pm, installer/InstallAuth.pm, and
t/db_dependent/Circulation.t would need to be modified. This
patch corrects C4::Context's set_userenv routine to be object
call based (use ->) by using a shift to ignore the first
parameter, and modify the three files found with :: calls.
As the result of trying to roll a distribution,
t/Circulation_barcodedecode.t was discovered to be faulty. The
cause being incorrect parameters! This was hidden when there
was no shift in the set_userenv routine. However, with its
correction, the test broke.
This led me to read the POD documentation for the function
set_userenv in C4::Context and realize it was outdated as
well. It has been revised to match the current version of
the function.
Then intentionally bad parameters passed to the set_userenv
routine in C4::Context were hunted down. The biggest problems
were missing surnames or branch names.
Rebase required because of shibboleth change in C4/Context.pm
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Test plan:
1: Go to your patron
2: Go to change username and/or password.
3: Change password to something with spaces in the middle. Notice it is invalid.
4: Apply this patch.
5: Change password again using spaces in the middle. Notice it is accepted.
6: Change password with leading and/or trailing spaces, notice they are not accepted.
Applied bothe patches. Followed test plan. Patch behaves as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Test plan:
Go to your patron, go to change username and/or password. change
password to whitespace, notice it is accepted, apply this patch,
change password again, to whitespace, notice password is not valid.
Followed test plan. Patch behaves as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
- Move database update entry to correct spot
- Fix version number in database update
- Fix capitalization in sys pref description
- Fix sequence in sysprefs.sql
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
There was an instance of the pragma missed which meant the the original
patch set didn't actually solve the problem in a large number of cases
This patch adds in the relevant statement.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Agree with Chris that the defualt should maintain the higher security
and not reduce it.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To Test:
1) Enable the system preference SessionRestrictionByIP
2) Change your system IP. It will not checkout your system IP or signout.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
In this special case (the suggestion is linked to "all funds"), the
budgetid value should be NULL in DB.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes old and new tests.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The DB field suggestions.budgetid should be linked to
aqbudgets.budget_id.
If the fund is removed, this column should be set to NULL.
Test plan:
1/ Using your SQL CLI (or equivalent), create or update 1+ suggestions and
set "0" in the budgetid field (or a nonexistent budget id).
2/ Execute the updatedabase script.
3/ Verify that your suggestion is unlinked to the nonexistent fund.
4/ Verify the constraint has correctly been added (show create table
suggestions).
5/ Check that this change does not affect the behavior on adding a
suggestion (linked to a fund or not).
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch fixes the translation for the "Remove" button.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Tested:
- acq history search with different searches
- patron lists patron search
Passes all tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If it's the result view, the autocomplete should not be apply to the
input element (it does not exist).
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This bug modifies not just the order search form but also the patron
lists feature, making use of the new script for building a patron
autocomplete form. However, the test plan does not specify that the
patron lists form be tested as well, and it doesn't work.
This patch corrects a minor flaw which broke the patron search
autocomplete when adding patrons to a patron list.
To test, create a new patron list if necessary. Click the "add patrons"
button to add patrons to the list. In the patron search form type a
partial patron name. You should get an autocomplete dropdown of existing
patrons. Selecting one should work correctly.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds the ability to search orders using the basket creator.
Test plan:
- go on the order advanced search form (acqui/histsearch.pl)
- use the autocomplete input to search patrons
- launch the search and verify the results are consistent with the
values you have filled.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The patron list feature uses an autocomplete field to search patron.
This will be reused in the next patch.
This patch should not introduce any behavior change.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 12944 [QA Followup] - Rename patrons.pl to patrons.js
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
It makes no sense to have TRUNCATE or foreign key checks.
TEST PLAN
---------
1) Back up your database
2) in an mysql client:
use kohadata;
SET FOREIGN_KEY_CHECKS=0;
TRUNCATE currency;
source /home/mtompset/kohaclone/installer/data/mysql/ru-RU/optional/sample_currency.sql
SET FOREIGN_KEY_CHECKS=0;
TRUNCATE currency;
source /home/mtompset/kohaclone/installer/data/mysql/uk-UA/optional/sample_currency.sql
SET FOREIGN_KEY_CHECKS=0;
TRUNCATE currency;
source /home/mtompset/kohaclone/installer/data/mysql/it-IT/necessari/parameters.sql
SET FOREIGN_KEY_CHECKS=1;
QUIT
-- These should all work without problem.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
It seems odd that only the holding libraries are listed on the holds
ratios report, we should add the home libraries as well.
Test Plan:
1) Apply this patch
2) Run the hold ratios report
3) Note the new home libraries column
Signed-off-by: Heather Braum <hbraum@nekls.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
The holds ratio report ignores ordered items. This could cause a library
to inadvertently order more copies of a title than they actually need.
An option should be added to count ordered items ( i.e. any negative
notforloan value ).
Test Plan:
1) Apply this patch
2) Create a record with two items, one regular, one ordered.
3) Place 3 holds on the item
4) Run the reserve ratios report, by default you should see this record
5) Check the new 'include ordered' checkbox, rerun the report
6) Note that record is no longer displayed
Signed-off-by: Heather Braum <hbraum@nekls.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Having $ordernumber as the parameter in a function which is
handling suggestions and it is used as a suggestion id is
confusing to the coder and person trying to read the code.
This patch corrects the confusion.
REVISED TEST PLAN
-----------------
1) perldoc C4::Suggestions
-- notice it says ordernumber for the GetSuggestions example.
2) Ensure you have CPL in your branches table.
3) prove -v t/db_dependent/Suggestions.t
-- if you have more than 8 itemtypes in your database, two
tests at the end will fail, but that is not relevant to
the modified GetSuggestions code.
4) apply patch
5) perldoc C4::Suggestions
-- notice it is corrected now.
6) prove -v t/db_dependent/Suggestions.t
-- it should run with the same results as in step 3.
That is, if you have 8 itemtypes, all pass, otherwise
those two tests fail.
7) run koha qa test tool
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Patch will add DDC classifications, divided with | below the subjects
in the OPAC and staff detail pages.
To test:
- catalogue a record with one or mulitple 082$a subfields
- verify the classifications are displayed in OPAC and staff detail page
- Add following CSS to OpacUserCSS or IntranetUserCSS:
.results_summary.ddc {
display:none;
}
- Verify the DDC classifications are now no longer displayed
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Test plan ok. Repetions of $a subfield are separated by a space, which seems
correct. I'm not sure whether other subfield than $a should be displayed on
intranet. Whatever, this could be added later.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The a patron's userid should be a matchpoint in the same manner as
cardnumber. Though not enforced as a unique key by the database yet
( pending bug 1861 ), this field is effectively unique as uniqueness
is enforced by Koha itself.
Test Plan:
1) Apply this patch
2) Browse to tools/import_borrowers.pl
3) Download the starter CSV file
4) Edit the csv file to include 1 or more patrons
* Make sure to leave the borrowernumber field empty
* Make sure the userid field matches the patrons you wish to overwrite
5) From import_borrowers.pl, upload your file
* Set "Field to use for record matching" to "Username"
* Set "If matching record is already in the borrowers table" to "Overwrite the existing one with this"
6) Click "Import"
7) Verify the patrons in your file have been updated in Koha
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Do exactly what's announced. This may help.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Changes are confirmed with author (Mirko Tietgen). See Bugzilla.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
System information indicates missing <zebra_bib_index_mode> and <zebra_auth_index_mode> entries in koha-conf.xml.
This patch
- adds warnings about a possible mismatch between these settings and the actual setup
- adds info about the actual setup/what values to use for <zebra_bib_index_mode> and <zebra_auth_index_mode> if they are not set.
The assumption is that a path including 'zebra-*-dom.cfg' in the respective section indicates a DOM setup.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds a sort of branches alphabetically by name in authorised values administration, like in many other pages.
Also replaces var $branch (too ambigus) by $branchcode.
Test plan :
- Create 2 branches : code=AAA,name=Zbranch and code=ZZZ,name=Abranch
- Create a new authorized value : admin/authorised_values.pl
- Look at "Libraries limitation" :
=> Without patch branches are sorted by code : Zbranch then Abranch
=> Without patch branches are sorted by name : Abranch then Zbranch
- Select a branch and save
- Re-edit
=> Check the same branch is selected
Followed test plan. Patch behaves as expected.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12979 refactored the way to display prices.
The price format configuration was duplicated everywhere it was used.
All calls looks good except the one in admin/aqbudgetperiods.pl
In this one, the prices are formatted for an edition field (input).
This means the input is incorrectly filled even if the user does not
update the field.
At the end, maybe should we manage formatted prices everywhere, even in
inputs, but it's not in the scope of this bug.
Technically, a new subroutine format_for_editing is added to the
Koha::Number::Price module.
It should be called everywhere a price is displayed in an input field.
At the moment, it only does a sprintf("%.2f"), but it is a first step to
let the number of decimals to display configurable.
To test:
1/ Verify the issue described is fixed (editing a budget with a total
amount > 1000 (With CurrencyFormat is US or FR).
2/ Verify you can edit a fund with a total amount > 1000
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Test plan:
1. Add 4 item search fields (in Administration › Items search fields):
a. 1 biblio field linked to a DB field
b. 1 biblio field not linked to a DB field
c. 1 item field linked to a DB field
d. 1 item field not linked to a DB field
2. Make sure you have some data in those fields to search on.
3. Go to item search page and do a search using these new fields, make
sure the result is correct.
Signed-off-by: Nick <nick@quecheelibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When editing a Patron's messaging preferences or borrower attributes, one cannot
save changes because 'userid' is not given as a parameter.
It shouldn't, but the
Check_Userid($newdata{'userid'},$borrowernumber) -check must have it.
REPLICATE THE ISSUE:
1. Find a Borrower.
2. Go to the details-tab.
3. Under "Patron messaging preferences" click edit to edit just the messaging
preferences.
4. Just save, no need to make any modifications.
5. Observe the error "Username/password already exists"
This happens to all/most of the sub-forms in the Borrower's Details-view.
AFTER THIS PATCH:
Check_Userid() get the $userid from the new parameters, or if not present, from
the koha.borrowers-table.
TEST FOR REGRESSION:
1. Edit a borrower normally. Notice no errors.
2. Edit a sub-form (Alternate address/Patron messaging preferences). Notice no
errors.
DISCLAIMER: You are free to steal/rip/modify/hack this patch to your soul's
extent without my permission. As long as it makes to Koha I am happy.
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: Tomas Cohen Arazi <tomascohen@gmail.com>
The batch patron modification tool's template was created without the
footer include at the bottom. Without the footer include the language
toolbar will not be displayed.
All page templates should include the global footer include:
[% INCLUDE 'intranet-bottom.inc' %]
To test:
- Install at least a second language
- Enable at least 2 languages (language system preference)
- Go to tools > Batch patron modification
- Verify that at the bottom of the page the language chooser is shown
Followed test plan. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
I don't understand at all the usefulness of $privshelflist and
$privtotshelves in C4::VirtualShelves::Page
They look useless.
If you deep in the git history, you will find
commit 25eb36f21f
Bug #2531 Cannot delete private shelf
I am not able to reproduce this issue after this patch
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Some SQL parameters are added to the wrong side of the list.
This effectively clears all private lists from view :)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
