Due to bad use of grep syntax if there is one or more Basket Users the result of grep is not equal to 0 and the borrower is allowed.
Test plan :
1- select system preference 'AcqViewBaskets' on 'user'
2- create 2 borrowers (A, B) with only permissions on acquisition :
group_manage
order_manage
order_receive
staff
3- login with A and create a basket
4- add a basquet manager other than B
5- relog with account B
6- you can see the basket
Apply the patch.
The basket is no longer visible.
1- relog with A
2- add basquet manager B
3- relog with B
5- you must see the basket
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
These 2 methods are called from the template in list context.
However since bug 18539 Koha::Objects->find can no longer be called in
list context.
Forcing the context to scalar fixes the problem and should not
introduced side-effects.
Test plan:
- Create a club template
- Create a club using this template
=> Without this patch you should no longer get the following error:
Template process failed: undef error - Cannot use "->find" in list
context at /home/vagrant/kohaclone/Koha/Club.pm line 51.
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
C4::Members::GetBorrowersWithEmail can be easily replaced with
Koha::Patrons->search({ email => $email });
Test plan:
Confirm that you are still able to use PKI authentication
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
At this point, there should not be any occurrences of
GetReservesFromBorrowernumber anymore.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
This patch replace the different calls to GetReservesFromBorrowernumber
with a calls to Koha::Patron->get_holds.
In some places we need to get a restricted set of holds, that's why we
process a search on this holds returned by ->get_holds (on the found
status for instance).
The changes are quite trivial and reading the diff should be enough to
catch bugs.
Test plan:
I would suggest to test this patch with patches from bug 17736 and bug 17737,
to place different kind of holds (biblio and item level, future and
past).
Then do a whole workflow to detect bug, view a record, delete record,
order, place a hold on an item which has been ordered, etc.
The hold's informations should always be the same without or without
these patches.
Tested both patches together, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Resolve warning from members/summary-print.pl:
"my" variable $itemtype masks earlier declaration in same scope
Test if find returns a Koha object in GetDescription.
Test if find returns a Koha object too in shelves.pl. While testing, I had
a crash on a biblioitem with itemtype NULL (bad record, but these things
tend to happen somehow.)
Can't call method "imageurl" on an undefined value at virtualshelves/shelves.pl line 253.
Same for opac/opac-shelves.pl.
Note: Did not add tests everywhere but generally, I have the impression that
we do not sufficiently test on the results of Koha::Object->find. Mostly we
just assume that it will find a record. Several reports include fixes to
resolve that wrong assumption.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
At this point there should not be any calls to this subroutine.
Signed-off-by: Lari Taskula <lari.taskula@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
The C4::Koha::getitemtypeinfo subroutine did the almost same job as
GetItemTypes. On top of that it returned the imageurl value processed by
C4::Koha::getitemtypeimagelocation.
This value is only used from the 2 [opac-]shelves.pl scripts. Then it's
better not retrieve it only when we need it.
Test plan:
Play with the different scripts touched by this patch and focus on item
types. The same description as prior to this patch must be displayed.
Note that sometimes it is not the translated description which is
displayed, but that should be fixed on another bug report. Indeed we do
not expect this patch to change any behaviors.
Signed-off-by: Lari Taskula <lari.taskula@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
TEST PLAN
----------
git grep -i getsupplierby
-- only the code removed and the test tweaked
git bz apply 18782
sudo koha-shell -c bash kohadev
prove -v t/db_dependent/Serials.t
qa -v 2 c 1
exit
-- sign off
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Test plan:
Run t/db_dependent/Virtualshelves.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Eric Gosselin <eric.gosselin@inlibro.com>
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The two new columns as mentioned in the commit message of the table
revision must be used in the codebase now.
Highlighting some changes in Koha::VirtualShel[f|ves]:
[1] Additional methods is_public and is_private.
[2] Method add_biblio did not check permissions. Does now. No impact on the
interface, but one call in the unit test was affected.
[3] Method remove_biblios is signficantly simplified. Removed a FIXME.
[4] Method can_biblios_be_removed now redirects to can_biblios_be_added.
A followup report may deal with unifying those routines.
[5] Condition in get_some_shelves changed.
[6] The reference to allow_add in get_shelves_containing_record can simply
be removed.
opac-shelves.pl and shelves.pl now pass the default setting of Owner only
to the template.
Templates shelves.tt and opac-shelves.tt now include the new permission
field with three choices as mentioned in the table revision patch.
opac-addbybiblionumber.pl and addbybiblionumber now need a check on
allow_change_from_owner; search conditions slightly adjusted to the new
permission scheme.
Test plan:
When we refer to visibility in the test plan, please check the Add to-combo
on opac search results and staff results. And check opac-addbybiblionumber
by clicking Save to Lists from opac results.
The step 'Check delete' means: open the list in opac and check if you see
the Delete button below the entries (only check, do not delete).
[ 1] Create private list I01 (perm=Owner)
[ 2] Check visibility: Seen.
[ 3] Add a book. (Change by owner should be allowed.)
[ 4] Check delete: Yes.
[ 5] Edit list I01, set perm=Nobody
[ 6] Check visibility: Not seen.
[ 7] Check delete: No.
[ 8] Share list I01 with another patron.
[ 9] Check visibility for the other patron: Not seen.
[10] Check delete for the other patron: No.
[11] Change permission of list I01 to Anyone (by owner).
[12] Check visibility for the other patron: Seen.
[13] Let other patron add a book (change is allowed).
[14] Let owner delete the same book again (change allowed).
[15] Create public list U01 (perm=Owner)
[16] Check visibility: Seen.
[17] Add a book. (Change by owner should be allowed.)
[18] Login as other user. Check visibility: Not seen. Check delete: No.
[19] Change permission of U01 to Nobody (by owner)
[20] As owner: Check visibility: Not seen. Check delete: No.
[21] As other user: Check visibility: Not seen. Check delete: No.
[22] Create public list U02 (perm=Anyone)
[23] Add a book by owner.
[24] Delete the same book by other user. Add another book.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
No test plan.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
In order to make the permissions easier, we will replace the columns
allow_add, allow_delete_own and allow_delete_other by two new columns
allow_change_from_owner and allow_change_from_others.
The distinction between adding or deleting an entry is no longer made.
If you have change permission, you can do both. Also deleting an entry
does no longer depend on who added the entry.
Formerly, the owner could always add entries. It is now possible to
make a list readonly.
We will not use the combination of owner=no and other=yes. This will
leave us three possibilities:
[1] owner=no, other=no: The list is read-only. No one can change
contents of the list. Naturally, the owner can edit permissions.
[2] owner=yes, other=no: Only the owner can change contents.
[3] owner=yes, other=yes: Anyone seeing the list can change contents.
This especially applies to shared lists and public lists.
The two database columns will be presented in the interface as one
permission field offering the three abovementioned options.
Test plan:
[1] Run the db rev.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Following the idea behind bug 10865, we are only showing the permissions
when the list is shared or public.
Adding a simple test in opac-shelves here.
Note 1: Since the owner can always add or delete entries, the permissions
will not be relevant anymore for a strictly private list.
Note 2: Staff view always shows the permissions. This could have been
changed here too, but that change is far less urgent (bug 10865 did not
touch staff view and bug 18228 will rearrange permissions anyway).
Test plan:
[1] Verify on OPAC that you see the permissions for a private list with
shares or a public list. And you do not see them for a private list
without shares.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
If you have disabled the pref OpacAllowPublicListCreation, your users are
not able to edit the list permissions for private/shared lists.
For a private list they may only be theoretically relevant, but for a shared
list they are relevant.
Since we do not always know the history of a list (has it been public or
shared, does it contains entries from other users) and therefore permissions
are even relevant for a currently private list, we should just allow editing
these permissions.
Test plan:
[1] Do not yet apply this patch.
[2] Disable OpacAllowPublicListCreation.
[3] Create a private list in OPAC. Edit the list. Verify that you do not
see the permission combo boxes.
[4] Apply this patch. Edit the list again. Do they appear now?
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Works as advertised.
We cannot LOCK the old_issues table here, other tables are accessed and DBIx::Class rename it with "me":
DBD::mysql::st execute failed: Table 'me' was not locked with LOCK
TABLES [for Statement "SELECT `me`.`issue_id`, `me`.`borrowernumber`,
`me`.`itemnumber`, `me`.`date_due`, `me`.`branchcode`,
`me`.`returndate`, `me`.`lastreneweddate`, `me`.`renewals`,
`me`.`auto_renew`, `me`.`auto_renew_error`, `me`.`timestamp`,
`me`.`issuedate`, `me`.`onsite_checkout`, `me`.`note`, `me`.`notedate`
FROM `old_issues` `me` WHERE ( `me`.`issue_id` = ? )" with ParamValues:
0='2'] at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1832.
Consequence: We could have a checkin refused if there is a race, but
this is the simplest and safest way to fix it.
The file
koha-tmpl/intranet-tmpl/prog/en/modules/help/patroncards/image-manage.tt
has a small translatability issue (sentence splitting by html tags).
This patch fixes it and adds a little bit more explanation about
uploading, using and replacing such images.
To test:
- Verify that text changes make sense
- Apply patch
- Go to Home > Tools > Patron card creator > Images and verify
that the page displays properly
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
File add koha-tmpl/intranet-tmpl/prog/en/modules/admin/currency.tt exposes
parts of template directives due to html tags inide directives. Fix it using
the HtmlTags filter.
To verify:
- Create a translation for a language 'aa-AA
- po file aa-AA-staff-prog.po / translate.koha-community.org for 17.05 contains a line
'%%]'%sCurrencies %s
To test:
- Apply patch on top of Bug 18665
- Recreate translation
- Verify that line above is gone
- Verify that in staff client currencies administration wors as before
Followed test plan and it worked as intended
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Bug 18684: (followup) Move 2 closing h3 tags to end of previous lines
See comment #4
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds tests for the tt filter HtmlTags.pm
To test: prove -v t/HtmlTags.t should pass
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
HTML tags inside template toolkit directives are not allowed because of translation issues.
Add a filter that handles HTML tags.
Note you need to write quotes ' around the text you want displayed as a
heading
To test:
- Apply patch
- Add [% USE HtmlTags %] to the top of a tt file
- Add something like [% 'My nice title' | $HtmlTags tag="h1" %] to the tt file
- Verify that in output 'My nice title' has h1 tags
- Change template directive to something like
[% 'My nice title' | $HtmlTags tag="h1" attributes='title="This is a nice title attribute"' %]
- Verify that title attribute displays in output (source code or tooltip on 'My nice title')
Notes: - Tests are planned for a second patch
- Update for Wiki coding guidelines
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The following test is failing on Jenkins:
# Subtest: Handle ids duplication
1..4
ok 1 - No account lines should exist on old issue_id
not ok 2 - Two account lines should exist on new issue_id
ok 3 - AddReturn should return the issue with the new issue_id
ok 4 - If an item is checked-in, it should be moved to old_issues even if the issue_id already existed in the table
not ok 4 - Handle ids duplication
When no circ rule exist
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Found this by inserting the same issue_id in old_issues before checkin:
The call to ->search( )->get_column is in scalar context and will
return the number of results, i.e. always 1.
If you have an issue_id 2 in old_issues, it will crash:
DBIx::Class::Storage::DBI::_dbh_execute(): Duplicate entry '2' for key 'PRIMARY'
The fix is fairly simple: Put get_column in list context and pick the first
array entry.
NOTE: Using DBIx's get_column()->max here might look simpler here.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Variable $original_issue_id is not used. The id is retrieved later from
$issue when updating accountlines.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
For more info, see:
commit be156d9ad9
Bug 15854: Use a READ and WRITE LOCK on message_queue
and
commit b40456f7dd
Bug 18364: Do not LOCK/UNLOCK tables from tests
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
If the "max(issue_id) from old_issue + 1" already exists in issues, the
move fails.
For instance we have
1, 2, 3, 4 in issues
checkin 4
1, 2, 3 in issues (AI=5)
4 in old_issues
Restart mysql => AI is reset to MAX(issue_id) => 4
checkout a new one
1, 2, 3, 4 in issues (AI=5)
4 in old_issues
checkin 4 (will get id 5 in old_issues)
1, 2, 3 in issues (AI=5)
4, 5 in old_issues
=> This works with and without this patch
Now we have
1, 2, 3 in issues (AI=5)
4, 5 in old_issues
Restart mysql => AI is reset to MAX(issue_id) => 4
checkout 2 new ones
1, 2, 3, 4, 5 in issues (AI=7)
4, 5 in old_issues
checkin 4 (4 becomes 6 in old_issues)
1, 2, 3, 5 in issues (AI=6)
4, 5, 6 in old_issues
=> This did not work without with patch
The update of the issue_id was made before the move (so in the issues
table), the PK did not allow it
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
2. If the move fails for whatever reason (see
https://lists.katipo.co.nz/pipermail/koha/2017-May/048045.html for an
example), fines can be charged. It should not
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
1. AddReturn returns a $issue hashref with the old issue_id value
=> At first glance it does not affect anything, but would be good to fix
it for future uses.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
This patch adds a check for the existence of various template variables
before showing the row containing that data. This will prevent the
display of rows containing labels but no data in the suggestions
detailed view.
To test, apply the patch and go to Acquisitions -> Suggestions.
View the detail page of various suggestions and confirm that only fields
with data are displaying.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
GetFictiveIssueNumber:
Returns undef instead of 0 for irregular frequencies. Also added to POD.
Removed unused variable $wkno.
Adding a return makes the if(unit) unneeded.
Replaced (a+b)/b by 1+a/b.
_delta_units:
Added a comment about its parameters.
GetFictiveIssueNumber.t:
Adjusted the tests for irregular frequencies accordingly.
Test plan:
[1] Run t/db_dependent/Serials/GetFictiveIssueNumber.t
[2] Run t/db_dependent/Serials/GetNextDate.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
No changes were needed for GetNextDate.t.
In GetFictiveIssueNumber.t we add a subtest for daily frequencies.
Test plan:
[1] Run t/db_dependent/Serials/GetFictiveIssueNumber.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The changes in _get_next_date_day are actually only cosmetic. The sub
now reads exactly the same as its counterparts for other units, but
the results are exactly the same as before.
In GetFictiveIssueNumber we now call _delta_units for each type of unit.
The two Delta_Days calls are moved to _delta_units. Note that this also
is a cosmetic change; results should be exactly the same.
Test plan:
[1] Edit a subscription. Test predication pattern for some daily freq.
[2] Run t/db_dependent/GetNextDate.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Corrections and added unit tests following the changes of the first patch.
GetFictiveIssueNumber.t: New subtest for weekly frequencies.
GetNextDate.t: Correcting a few dates one day. If we use 2/week, we will
calculate an interval of 3 days and correct with 4 days at the end of
the cycle. The connection with firstacqui is not relevant anymore.
Test plan:
[1] Run t/db_dependent/Serials/GetFictiveIssueNumber.t
[2] Run t/db_dependent/Serials/GetNextDate.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Same solution applied as in bug 18356/18607. Consistency++
The code in _get_next_date_week is again very similar to the code in
_get_next_date_month or _get_next_date_year. I will not merge them here,
but we could consider that in the future.
Code in GetFictiveIssueNo has been adjusted similarly to month and year.
Test plan:
[1] Do not apply this patch. Create a subscription for 3/week.
When the first issue date is on a Saturday or Sunday, the
intervals in the prediction pattern are 0,0,7,0,0,7,etc.
Starting on Wed-Fri 1,1,5,etc. Starting on Mon-Tue 2,2,3,etc.
[2] Apply this patch. Check again.
The interval should be always 2,2,3 now and no longer depend on the
day_of_week of first issue date.
[3] Check another weekly frequency with multiple units per issue.
Say 1 issue/3 weeks.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The changes in the first patch require some corrections as well as
additional test cases.
GetNextDate.t: Since the calculation for multiple issues per unit has
slightly changed, a few dates (day 15 or day 16) have been changed in the
unit test; when we use 2/month, the algorithm now always adds 15 days.
Added a few test descriptions in this regard too.
GetFictiveIssueNumber.t: Add the monthly subtest with two test cases. In
the first case we tests multiple units per issue, and in the second case
we test multiple issues per unit (month).
Test plan:
[1] Run t/db_dependent/Serials/GetFictiveIssueNumber.t
[2] Run t/db_dependent/Serials/GetNextDate.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Similarly to the solution of bug 18356, this patch fixes the date
calculation for monthly frequencies.
The calculation in GetFictiveIssueNumber now makes use of the new
_delta_units sub introduced on bug 18356.
The calculation in _get_next_date_month is also very similar to the one
in _get_next_date_year. I do not merge them here, but this could still
be considered later on. At least consistency is achieved now between
both routines. The connection with firstacquidate has been cut thru
just like for year units.
Test plan:
[1] Without this patch, look at the prediction pattern for a
subscription with first issue on Feb 21 and 5 per month. The first
issues will be 21, 22, 23, 24, 25. Then jumping to 21, 23, 25, etc.
[2] Apply the patch. Look at the same prediction pattern. You will now
see 6 day intervals and a new cycle starting on the 21st.
So Feb 21, 27, Mar 5, 11, 17 and Mar 21, 27, etc.
[3] Edit an subscription. Try a few other monthly frequencies.
[4] The next patch adjusts related unit tests.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The problem as described on BZ 18356 is a combination of an error in
GetFictiveIssueNumber and GetNextDate for unit==year.
[1] In GetNextDate the Add_Delta_YM calculation should be applied only to
frequencies based on years per unit.
In the case of multiple units per year we calculate the number of days to
add. And if we have reached the end of a cycle, we correct the
rounding applied in the cycle.
NOTE 1: We obsolete the idea here of rebasing dates on firstacqui. In case
of manual adjustments, we probably do not want it. And otherwise we do not
need it anymore due to the correction at the end of a cycle.
NOTE 2: The calls to Add_Delta_YM are intentionally not corrected for leap
years. Say you start at 2016-02-29. If you use 1/yr or 1/2yr, you will
switch to the Feb 28th in the following years. In 2020 there will be no
switch to Feb 29 again; if someone should need it, please use a manual
adjustment. This is probably highly exceptional.
[2] In GetFictiveIssueNumber the year should be decreased by one if you
have more units per year and you did not yet reach firstacqui day and
month. This affects calculations in GetNextDate with irregularities.
NOTE 1: I added a wrapper around Date::Calc::N_Delta_YMD in order to improve
its results; this will especially be needed when we use it later for
month units.
NOTE 2: In case of manual adjustments this calculation does not really make
sense. Another report should deal with improving irregularities.
Test plan:
[1] Verify that both GetNextDate.t as well as GetFictiveIssueNumber.t pass.
[2] Look at the prediction pattern for a few frequencies.
For example: 1 iss/y, 1 iss/2y, 5 iss/y.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch deals with tests for yearly frequencies.
Adjust/extend GetNextDate.t:
[1] Adjust mixup of units/issues in a description.
[2] Add testing +2 years on 29-2 of leap year for freq 1 issue/2 years.
[3] Add tests for freq 9 issues/year.
Add GetFictiveIssueNumber.t:
[1] Two subtests are provided for irregular frequencies (very trivial) and
for year frequencies (with four specific test cases).
Test plan:
[1] Run t/db_dependent/Serials/GetNextDate.t
[2] Run t/db_dependent/Serials/GetFictiveIssueNumber.t
Note: Without the second patch both tests should fail. This shows the need
of the adjustments in the second patch.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
get() does not take two parameters. fixed.
prove and run koha qa test tools
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Several things are wrong here:
1. It assumes that import_record_id is the biblionumber
=> Wrong, it is only true when the DB is empty and that the 2 AI equal 1
2. The encoding in the template is 'UTF-8', not 'utf8', it leaded to
"stage-marc-import.pl: marc21record.mrc: Unexpected charset UTF-8, expecting utf8"
3. We did not test that the biblio was correctly imported
Test plan:
Make sure the tests now pass.
For the www tests you need to set the following env vars:
KOHA_USER, KOHA_PASS, KOHA_INTRANET_URL and KOHA_OPAC_URL
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Since bug 18242: When a biblio is deleted, a new transaction is created.
tools/manage-marc-import.pl use the AutoCommit flag, which does not
allow nested transaction.
AutoCommit must not be used.
Test plan:
Import a batch, then revert it.
The biblios must have been correctly deleted, they were not before this
patch
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
