Commit graph

8 commits

Author SHA1 Message Date
morgane alonso
cffb47ac5d Bug 17047: subscriptions management with Mana-KB
- add a class SharedContent.pm to communicate with Mana-KB server
- add a link in serials-menu.inc to serials_search.pl to open
a mana-subscription research form
- modify the research form in serials-search.tt to show the right fields
for Mana-KB
- create datatable in mana-subscription-search-result.inc to show
results from a research on Mana-KB
- modify serials-search.pl to manage research on Mana-KB

- add a mana_id to subscription table
- add a share button on serials-toolbar.inc and a modal to ask
the language of the share and to alert if the subscription is
already link to a Mana-KB subscription model
- add function in C4/Serials to get all the info for a subscription
sharing
- modify subscription-detail.pl to manage sharing to Mana-KB

- modify subscription-add.tt and subscription.pl to manage a
import from Mana-KB during a subscription creation
- add 2 script in svc for ajax calling from subscription-add.tt
to communicate with Mana-KB server during a asubscription creation
- add a function in Subscription.pm to have all the info for a Mana-KB research
from a biblionumber
- modify functions used by subscription-add.pl in C4/Serials to manage a
frequency which came from Mana-KB server and not already created on the
koha database, and modify the tests of the said functions

Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Rebased-by: Alex Arnaud <alex.arnaud@biblibre.com> (2018-07-04)
Signed-off-by: Michal Denar <black23@gmail.com>

Signed-off-by: Michal Denar <black23@gmail.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-01-23 14:39:26 +00:00
e25f4670f3 Bug 18697: Adjusting unit tests for weekly serial frequencies
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>
2017-06-19 15:35:51 -03:00
05a49035cc Bug 18607: Adjusting unit tests for monthly serial frequencies
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>
2017-06-19 15:35:50 -03:00
285f6bd945 Bug 18356: Extend GetNextDate.t, add GetFictiveIssueNumber.t (unit=year)
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>
2017-06-19 15:35:45 -03:00
Olli-Antti Kivilahti
0057fa933a Bug 12671: Guess next serial date when there are several issues per unit. Added support for real month and year lenghts.
When getting the next frequency number, use the real number of days for each month and each year.

Unit tests updated.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-05-05 15:22:10 -03:00
Julian Maurice
8b94c89f0b Bug 12671: Guess next serial date when there are several issues per unit
This guess uses the following algorithm
1/ Get the number of days remaining from first issue of this unit of
time until the end of the unit of time (using 7 days for week, 28 for
month and 365 for year)
2/ Divide it by the number of issues per unit
3/ Take the integer part of the result, this is the number of days to
add to previous serial published date

This patch also try to guess the date of the first issue of a unit of
time. Before that, it was:
- for week: monday of week
- for month: 1st day of month
- for year: 1st day of year
Now it uses firstacquidate.

Example:
  firstacquidate = 1970-01-07 (wednesday)
  unit = week
  issuesperunit = 2 (2 issues per week)

  From wednesday to sunday, there are 4 days so we add 2 days to get the
  next date.
  The next dates should be:
  - 1970-01-09 (+ 2 days)
  - 1970-01-14 (wednesday of next week)
  - 1970-01-16 (+ 2 days)
  - ... and so on

Test plan:
1/ Go to numbering pattern creation page (Serials -> Manager numbering
patterns -> New numbering pattern)
2/ In "Test prediction pattern" fieldset, set subscription length to 50
issues (this avoid to compute the next 1000 dates, which can take time)
3/ Fill first issue publication date
4/ Choose the frequency you want to test
5/ click on "Test pattern" button
6/ Check that the dates are correct
7/ Repeat steps 3-7 until you think you have tested enough cases

Interesting frequencies to test:
- 1/day
- 1/week
- 2/week
- 6/week (firstacquidate should be monday or tuesday, or the generated
  dates will be the same for all the week)
- 1/month
- 2/month
- 3/month
- 1/year
- 2/year
- 3/year

----------------
Sign off report:
----------------
-Followed the test plan. Unit tests work. Also trying some more strange
 frequencies with our librarians:
 5/year, 43/year, 10/year.
-Received all serials for a subscription and found no errors.
-Received some serials with frequency 2/month pre-patch, getting publication
 date as 1st of every month for each magazine. Having applied the patch,
 publication dates started working mid-subscription for new magazines.
-Works well and fine!
Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-05-05 15:22:10 -03:00
Julian Maurice
47a9afcb7e Bug 12003: Do not calculate next pubdate for irregular subscriptions
Show 'Unknown' when planneddate and publisheddate cannot be calculated

Also fixes SQL query in misc/cronjobs/serialsUpdate.pl that was still
using "periodicity != 32" to exclude irregular subscriptions from
results

Test plan:

1) Create a subscription in the serials module. Make sure to choose:
   Frequency = Irregular
2) Test the prediction pattern, first publication date is set to
   "First issue publication date" field, others will show as
   'unknown'
3) Save the subscription
4) Check the created issue - it will show a published date and a
   planned date (same as "First issue publication date" field)
5) Receive the issue and check the next generated issue, planned
   date and published date should show as 'Unknown'
6) Generate a next issue, planned date and published date should
   also show as 'Unknown'

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described following test plan.
No koha-qa errors

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Also tested:
- multi receiving generates mulitple issues without dates - 'unknown'
- staff detail page shows the dates empty, which is fine
- OPAC detail page shows the dates empty, which is fine
- serial collection page shows 'unknown' and those issues appear
  on the 'manage' tab, as they did in the past
- Editing the issue from the serial collection page leaves the
  date fields empty.
- Receving the issue, setting the status to 'Arrived' the Expected on
  date is set to 'today' automatically. Date published has to be
  entered manually (maybe something we could improve later
- subscription detail > issues tab shows Uknown.
- t/db_dependent/Serials/GetNextDate.t pass.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-18 20:57:51 +00:00
Julian Maurice
8f31154cbc Bug 7688: (follow-up) add unit tests for C4::Serials::GetNextDate()
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-10-30 00:37:58 +00:00