Script memberentry.pl contained a similar line.
Solution is simpler here.
Test plan:
[1] Add, change or clear the sms number at staff side.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This is an issue discussed on older reports already in the past.
Column mobile in borrowers is actually 'Other phone', not necessary a
mobile number. The name of the field is confusing. (Renaming it is
outside the scope of this report.)
The field that we are editing here is smsalertnumber. It should not be
compared with mobile at all.
What could be the side-effect of this correction?
===
First, the change is only relevant for libraries with pref SMSSendDriver
enabled.
In the past patrons editing their message preferences saw mobile (read:
other phone) in their smsalertnumber field (if the latter was still empty).
If they saved it, it was copied to smsalertnumber.
This change does not affect these patrons. They just have the same number
in two columns. No big deal.
What if a patron does not yet have a smsalertnumber? In that case no sms
is sent in Letters.pm. So no change in behavior. If he submits
opac-messaging now, he will no longer copy his other phone to smsalert [we
cannot assume that it was mobile anyway!]. If he enters a mobile number,
it will be saved correctly in the right field.
Conclusion: this change will not break things or hurt anyone. It only
prevents unwanted copying other phone to smsalertnumber.
Also modified the compare to prevent uninitialized warnings.
And removed a commented warn.
Test plan:
[1] Add, edit or delete the SMS number on opac-messaging regardless of
the value of Other Phone (in the badly named mobile field).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Enables to clear SMS number.
To test:
1. Go to opac-messaging.pl
2. Insert SMS number and submit
3. Clear SMS number and submit
4. Observe that the sms number did not change
5. Apply patch
6. Clear SMS number and submit
7. Observe that the sms number changes
Sponsored-by: Vaara-kirjastot
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Adding a follow-up.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
I have been working with messaging preferences and I noticed a weird issue in Firefox on Ubuntu.
On messaging preferences page, the table is unsorted and the content in rows are generated randomly
on every page refresh. When you select/deselect checkboxes and refresh the page (without posting the changes),
Firefox will remember your choices. Now the issue is that when the table is unsorted and the rows keep
changing on page refresh, Firefox has trouble remembering your choices. This makes it appear as if the
checkboxes are magically changing values on each page refresh.
Here is a patch that prevents this problem by sorting the messaging settings.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If an item is on reserve for two courses but one of those courses is
disabled, both courses are still listed on opac-detail.pl!
Test Plan:
1) Enable course reserves
2) Create two courses
3) Place one item on reserve for both courses
4) Disable one of the two courses
5) View the record details for that record/item
6) You should see both courses listed in the course reserves column
7) Apply this patch
8) Reload the page
9) You should now only see the active course in the course reseves column
Followed test plan. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
At the opac, the renew checkbox should not be displayed if it's an
on-site checkout (same on the intranet).
On the way, this patch adds a specific message to the intranet if the
librarian try to renew an on-site checkout.
Indeed before this patch a renew was allowed if the barcode was scanned.
Test plan:
1/ Create an on-site checkout for a patron
2/ Confirm that the checkbox 'renew' is not displayed on the checkout
list tables
3/ At the OPAC, the renew should not be allowed (no checkbox)
4/ Try to check the item out to the same patron, confirm that you get a
specifig message to inform you the renew is not allowed for on-site
checkouts.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Changed 'issue' to 'item' in the error message.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch makes the 'schema' param mandatory. It is passed in every
call on the current codebase, so it makes no harm now, but makes
the code less error-prone.
Tests for this situation are added to t/Koha_MetadataRecord.t (schema
param is omitted and new() returns undef and a carped warning).
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The description of this changes is on the regression tests commit
message.
To test:
- Apply the test patch
- Run
$ prove t/Koha_MetadataRecord.t
=> FAIL: Tests fail because changes are not implemented
- Apply this patch
- Run
$ prove t/Koha_MetadataRecord.t
=> SUCCESS: tests pass
- Run
$ prove t/Koha_Util_MARC.t
=> SUCCESS: it still passes
- Sign off :-D
NOTE: Tested as above. Read code. Seems to cover all cases.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
In order to use Koha::MetadataRecord as a container for moving records
around it is important to let it carry the serialization format
of the record object it was built with, so it is easier and cheaper to
make decisions about records.
This patch introduces regression tests for the changes to be made.
The 'format' param is introduced, and also sets default values:
schema => 'marc21'
format => 'MARC'
A new (optional) 'id' param is added so the record carries its own id outside
of it.
The default behaviour is preserved, and no changes are needed in places
Koha::MetadataRecord is used.
->new also returns undef if no record is passed, and raises a carped warning.
To test:
- Apply this test patch
- Run the new tests
$ prove t/Koha_MetadataRecord.t
=> FAIL: Tests shoud fail as the changes are not implemented on Koha::MetadataRecord
Edit: made serialization format be upper-case to match what is used on Koha::Filter's
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The names are much better now :)
Combined the queries for items and issues.
Only check the number of holds when needed.
Test plan:
Verify the changes here by running the unit test again.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Run the test: t/db_dependent/Reserves/GetReserveFee.t
Signed-off-by: Joonas Kylmala <j.kylmala@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The code of GetReserveFee was not very clear.
What it did was: check if there are some items not issued. If so and there
are no holds, calculate no fee.
While doing so, I moved the code to charge the fee (in AddReserve) to a small
new sub ChargeReserveFee.
There is no change in behavior.
The follow-up patch adds unit tests.
Test plan:
[1] Make sure that a patron category (X) includes a hold fee.
[2] Select a biblio with 2 items.
[3] Issue one item to another patron.
[4] Place a hold on this biblio by patron with category X. No charge?
[5] Cancel the hold from the previous step.
[6] Use another patron to place another hold on this biblio.
[7] Place hold again by patron with category X. Is it charged?
[8] Cancel that hold again. Issue the second item to another patron.
[9] Place hold again by patron with category X. Is it charged again?
Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If you add patron to a patron list, from the patron search result, a
list is created when you click on "Save".
The list is considered as new each time.
To reproduce:
1/ Launch a patron search
2/ Select 1 patron, and create a new list 'aaa'
3/ Select another patron and click Save again
2 lists are created
Test plan:
1/ Launch a patron search
2/ Select 1 patron, and create a new list 'aaa'
The dropdown list should be populated with this new list, and should be
selected
3/ Select another patron and click Save again
Only 1 list should be created
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@theke.io>
On the patrons home page, the dropdown list is not populated.
Test plan:
1/ Go on the patrons home page (members/members-home.pl)
2/ Launch a search
3/ The dropdown list close to "Add selected patrons to" should contain
all your patron lists
NOTE: Initially tested with both which created lists.
git reset --hard origin/master
And then dropdown list was missing them.
Applied just this one, and they were listed.
Signed-off-by: Mark Tompsett <mtompset@hotmail.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@theke.io>
It does not make sense to have 2 paginations here.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Numbered links have incorrect url. Links to result pages
don't work in Receive Shipment List (but fortunately, Next
and Previous buttons work) It's because the booksellerid is
not furnished in the url.
Test Plan :
1) Go to Acquisitions module, enter a bookseller name that you
know you can get many page of invoices for and search for it.
2) click on Receive shipment button.
3) On bottom of the first results page, click on page number 2
link. (cf joined screencast)
You'll see that the results include invoices from other
booksellerid. Indeed, I suppose that you get results from all booksellerid.
Intall patch and redo 3 steps.
NOTE: I did not follow this test plan.
I read the acqui/parcels.pl code.
The template parameter numbers is assigned in a function which has
no reference to booksellerid at all!
Additionally, the booksellerid is set directly elsewhere.
It is also strange that the booksellerid references before and after
this loop do not use the numbers.booksellerid, but just booksellerid.
The change from numbers.booksellerid to booksellerid is correct!
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Now that fund name is displayed in the table as a link, you see that arg budget_period_id is never defined in this link.
This is because the template var is [% budget_line.budget_period_id %] instead of [% budget_period_id %].
This looks like a mistake when converting from tmpl to tt.
Test plan :
- Without patch
- Look for a planning with funds :
/cgi-bin/koha/admin/aqplan.pl?budget_period_id=2&authcat=MONTHS
- Click on a fund name
=> You see in URL that budget_period_id is empty :
/cgi-bin/koha/admin/aqbudgets.pl?op=add_form&budget_id=6&budget_period_id=
- Apply patch
- Look for a planning with funds :
/cgi-bin/koha/admin/aqplan.pl?budget_period_id=2&authcat=MONTHS
- Click on a fund name
=> you see in URL that budget_period_id is defined like in planning page :
/cgi-bin/koha/admin/aqbudgets.pl?op=add_form&budget_id=6&budget_period_id=2
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@theke.io>
A patch from bug 11714 removes 'budget_name_indent', which was useless.
The script and the template should use the budget_name value.
Note that this patch impacts the CSV export, which does not work, so it cannot be
tested.
Test plan:
Edit a fund and click on one of the Planning value (by months, etc.)
The "Fund name" column should be correctly populated with the fund
names.
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.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@theke.io>
Right after checking out, a small box appear with "Checkout out: Some Title (32154001669305). Due on 24/09/2015".
The title doesn't appear anymore (since the move to db schemas). This fixes it.
Test:
1) checkout ANY item, for ANY user
2) Look at summary right below the checkout input box. The title doesn't show up.
3) apply patch, reproduce same steps (after checkin if same item). Title appears.
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Todo: You need to track what are the queries generated here.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
to test..
1/ run t/Creators.t test from git repo, get a FAIL
2/ apply patch
3/ repeat step 1, get a PASS
mason@xen1:~/g/k/3.16.x$ sudo koha-shell -c 'export PERL5LIB=/home/mason/g/k/3.16.x ; cd /home/mason/g/k/3.16.x ; prove -v t/Creators.t' k316x1
t/Creators.t ..
1..16
ok 1 - use C4::Creators;
ok 2 - use C4::Creators::PDF;
ok 3 - testing new() works
ok 4 - testing pdf file created
ok 5 - testing Add() works
ok 6 - testing Bookmark() works
ok 7 - testing Compress() works
ok 8 - testing Font() works
ok 9 - testing FontSize() is set to 12 by default
ok 10 - testing FontSize() can be set to a different value
ok 11 - testing Page() works
ok 12 - testing StrWidth() returns correct point width
ok 13 - testing Text() writes from a given x-value
ok 14 - testing Text() writes to the correct x-value
ok 15 - testing End() works
ok 16 - test file /tmp/4YjPQDExeS created OK
ok
All tests successful.
Files=1, Tests=16, 1 wallclock secs ( 0.03 usr 0.01 sys + 0.48 cusr 0.05 csys = 0.57 CPU)
Result: PASS
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When having more than 20 (or numSearchResults) reviews waiting to be approved in <site>/cgi-bin/koha/reviews/reviewswaiting.pl?status=1,
the paging at the bottom only offset by 1 entry, instead of moving a full page (20 entries) ahead.
The simple fix uses 'page' instead of 'offset'.
TEST:
1) Modify numSearchResult preference to a low (5?) value.
2) create X comments, where X is greater than the value above.
3) approve them all (although this step is probably unnecessary)
4) Go to tools >> comments (approved comments tab)
5) You see X entries. Click on page 2 at bottom. Link should show "offset=2")
6) You get same results, except the first one which "slided out".
Apply patch, redo step 4-5.
With patch, paging works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Follow-up for
- it-IT unimarc
- ru-RU unimarc
- uk-UA unimarc
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To Test
---------
1) Apply the patch
2) Export some MARC bibliographic records from Koha
3) Import those same MARC bibliographic records using the
"ISSN(022$a)" record matching rule.
4) The incoming records should match perfectly
5) Check the mysql tables (marc_matchers, matchpoints,
matcher_matchpoints, matchpoint_components,
matchpoint_component_norms) to make sure the values were
inserted as expected.
For new Koha installation
1) create the koha database
2) Go to the staff client page, and do a "fresh" install making
sure to select lots of optional marc 21 matching rules so
the .../marc21/optional/marc21_default_matching_rules.sql
gets triggered.
3) Check the mysql tables (marc_matchers, matchpoints,
matcher_matchpoints, matchpoint_components,
matchpoint_component_norms) to make sure the values were
inserted as expected.
Bug 14472 - Added Atomic Update to fix wrong issn search index
- Fix comments
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch implements the copy and replace action for the marc
modification templates.
Instead of copying a field/subfield, it will erase the destination
fields/subfields.
Test plan:
Find it yourself.
Compare the differences between the copy and the copy_and_replace
actions.
The easier way to test is to 1/ create a complete record, 2/create some
modification templates and 3/ use the batch record modification with the
"preview" function.
QA note: I kept the same tests as "copy" and, if no change were
expected, I noted them "(same as copy)", to be sure this new action won't
introduce regression on these tests.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch add the new value for the MTT action.
It updates the marc_modification_template_actions.action DB field to
allow 'copy_and_replace_field'.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Just some cleaning before to continue, _copy_field and _copy_subfield did not
do anything useful.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
There is an inconsistency in the copy action:
Given the following control sample:
245 _aThe art of computer programming
_cDonald E. Knuth.
300 _aA_exists
_bB_exists
If we apply action (a) Copy the whole field 245 to 300, we get:
245 _aThe art of computer programming
_cDonald E. Knuth.
300 _aA_exists
_bB_exists
300 _aThe art of computer programming
_cDonald E. Knuth.
If we apply action (b) Copy the subfield 245$a to 300$a, we get:
245 _aThe art of computer programming
_cDonald E. Knuth.
300 _aThe art of computer programming
_bB_exists
In (a) the field is copied but in (b) the subfield is erased.
We should be consistent and don't erase the destination field.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When getting records from OAI-PMH, an error must be returned if there is no results.
See : http://www.openarchives.org/OAI/openarchivesprotocol.html#ErrorConditions
Test plan :
- Enable OAI webservice
- Perform a query that will return no results. ie : /cgi-bin/koha/oai.pl?verb=ListRecords&metadataPrefix=marcxml&from=2099-12-30&until=2099-12-31
=> Without patch you get a response with :
<ListRecords/>
=> With patch you get a response with error code :
<error code="noRecordsMatch">No records match the given criteria</error>
- Check a good query returns still results
- Same test with ListIdentifiers verb
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Add subfields l, n and o for better UNIMARC compliance
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Note: I just did a code audit here, as I don't know enough about
UNIMARC to know if the 4XX fields should have these subfields.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
In some situations (bad migrations, old bugs that introduced bad data,
people having bib-level itypes for ages and switching to item level...)
the user ends with undex itype values for items.
The current code, if the user has item_level-itype set, just returns
undef. It should fallback to bib-level. In order to avoid hiding the problem
a warning is raised.
To test:
- Run the regression tets:
$ prove t/db_dependent/Items.t
=> FAIL: tests fail.
- Apply the patch
- Run the tests again
=> SUCCESS: The tests now pass.
- Sign off :-D
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Koha::Item->effective_itemtype should fallback to biblio-level itemtype
even if item-level item types are set, in the case the item has no itemtype
set (bad migration, bad old code).
To test:
- Run
$ prove t/db_dependent/Items.t
=> FAIL: Koha::Item->effective_itemtype doesn't work properly
Edit: Added a test for a warning when falling back as per QA request
and because it made a lot of sense :-D
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
http://bugs.koha-community.org/show_bug.cgi?id=14717
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test
1/ Import a patron using the patron import tool, make sure they have
no debarred column in the file
2/ Check the database, notice the debarred column is 0000-00-00
3/ For bonus points, checkout an item to that borrower, then check it in
notice Koha errors
4/ Apply patch
5/ Import a new patron
6/ Notice column is now NULL and that checkins work
Signed-off-by: Eugene Espinoza <eugenegf@yahoo.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When AutoBarcode is activated and you have set AcqCreateItem to 'on
order' there is a Javascript error when you try to generate a barcode
for the item:
TypeError: document.f is undefined
http://localhost:8080/intranet-tmpl/lib/jquery/jquery.js
Line 11
Test plan:
0/ a. Set AutoBarcode to hbyymmincr
b. Set AcqCreateItem to 'on ordering'
c. Set the plugin barcode.pl to the barcode field for the default
and the ACQ frameworks
1/ Go on the add items page (cataloguing/additem.pl) and confirm that
the plugin works as expected.
2/ Go on the New order page (acqui/neworderempty.pl) and confirm that
the plugin works as expected.
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: Tomas Cohen Arazi <tomascohen@theke.io>
This patch introduces entries for monthly running the share_usage_with_koha_community.pl
script to the packages and also the crontab.example file for manual
installs use.
Edit: I fixed the Copyright line
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If IdependentBranches is ON, to edit/delete items from other branches
you need to be superlibrarian.
Currently a "simple" staff user cannot edit them from the edit item page
but from the catalogue detail page.
The edit links should not be displayed on this table.
Test plan:
O/ Set IndependentBranches to "Prevent".
Create a record and add 2 items:
Set homebranch to L1 for item I1.
Set homebranch to L2 for item I2.
1/ With a superlibrarian user, you should be able to edit both items.
2/ With a "simple" user attached to L1, you should only be able to edit
I1. The edit links should not be displayed for I2.
Note that the checkbox is displayed on the catalogue detail page (item
list), but on the batch tools, it won't be possible to select non-modifiable
items.
TODO: Add a server-side check. Indeed it is still possible to edit an
item if the user know the url.
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: Tomas Cohen Arazi <tomascohen@theke.io>
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: Tomas Cohen Arazi <tomascohen@theke.io>
The change in MoveReserve from the previous patch begs for a test.
Here we add some to Reserves.t.
In all six tests we place a hold, move it and check the reserves again.
Depending on the status of ConfirmFutureHolds, and the reservedate the
hold should be moved or not.
Test plan:
Run the unit test.
Bonus: If you run Reserves.t by applying this patch but without the first
patch that changed MoveReserve, tests 60 and 61 should fail:
not ok 60 - MoveReserve filled future hold now
not ok 61 - MoveReserve filled future waiting hold now
This may further illustrate the need of the first patch.
Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
At checkout a hold for the same borrower is considered to be filled.
It is consistent to do the same for holds of the same borrower within
[ConfirmFutureHolds] days (if non-zero).
This goal is achieved by adjusting the CheckReserves call within
MoveReserve, adding the lookahead parameter.
I used this occasion to revisit other calls of CheckReserves:
- transferbook: no need to add lookahead; a future hold should not block
a transfer;
- CanBookBeIssued: no lookahead; future hold does not block an issue;
- CanBookBeRenewed: idem.
- GetOtherReserves (only used in circ/returns): this call might be a
candidate for lookahead too, but I leave that for another report. It is
in the context of checkin and transfer, not checkout.
Test plan:
[1] Set ConfirmFutureHolds to zero days. (You may also need to enable
AllowHoldDateInFuture.)
[2] Place a hold with borrower A on biblio X for tomorrow. Also place a hold
with borrower B on X for today. (Use biblio level holds.)
[3] Check out item Y of X to borrower A. Ignore the warning for borrower B
and do not cancel the hold of B (so: confirm checkout).
Verify that X has still two holds.
[4] Check in Y (without confirming a hold).
[5] Enable ConfirmFutureHolds, say 2 days.
[6] Check out Y to A again. Ignore the warning for B (no cancel). Verify that
X now only has one hold for borrower B (the hold for A was filled).
Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
- prove t/db_dependent/Letters.t
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Currently it's not possible to include information about which
issue has arrived in the serial notification notice the patron
can subscribe to from the OPAC.
The patch makes the fields from the subscription and serial
table available to the notice template.
In order to be able to print information about the correct
issue, the GetAlert has been modified to expext the serialid
as externalid when the module is issue.
git grep SendAlerts (only call with 'issue' is in Serial.pm)
To test:
- Add a subscription, select a patron notification template
- Search for the record in the OPAC
- Go to the subscription tab - More details
- Subscribe to the notification
- Edit the notice template you selected for the subscription
- add fields from subscription
- add fields from serial (serial.serialseq has the issue
information)
- Receive an issue for the subscription
- Check that you have received the notification and that
all information has been printed correctly
NOTE: notice is sent directly, not through the message_queue
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
On creating an item type, if it already exists, it will replace the
existing one.
This patch prevent that and display a message to the interface.
Note: The fields are lost.
Test plan:
1/ Create an item type 'AAA', description 'AAA'
2/ Edit it, update the description with 'BBB'
3/ Create an item type 'AAA' with a description 'CCC' => you should get
a warning "already exists".
Works well, no errors
Signed-off-by: Amit Gupta <amit.gupta@informaticsglobal.com>
Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Warning message is triggered.
Adding, editing and deleting item types still works.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The special regex chars are not escaped in C4::HTML5Media.
Test plan:
1/ Set 856$u=http://www.mrqe.com/lookup?talented+mr.+ripley
2/ Enable the pref HTML5Media
3/ Go on the detail page
It should not explode.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
On the edit items page, there is some weird JS code: if the user clicks
on the delete link and then cancel, the item is deleted anyway.
It's caused by the following JS code in browser.js
$('a[href*="biblionumber="]').click(function (ev) {
ev.preventDefault();
window.location = $(this).attr('href') + '&searchid=' + me.searchid;
});
Test plan:
- Do a search with multiple results
- Go to the detail page (make sure results browser shows up!)
- Use the "Edit items" link from the toolbar
- Delete an item (try both way)
- Choose "cancel"
- Delete an item (try both way) and confirm the deletion
You should see the browser after the deletion and the item should have
been deleted correctly.
- Edit an item (try both way)
You should see the browser (did not work before this patch)
Note: Before this patch, the 2 first columns didn't contain the
edit/delete item links, now it's only the 1st one.
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Much better!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The unit test is db dependent (as Jonathan correctly remarked),
since the sub checks a preference.
Test plan:
Run t/db_dependent/Biblio/TransformHtmlToXml.t
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: Tomas Cohen Arazi <tomascohen@theke.io>
