Bug 15148 - Serials: Test prediction pattern starts at First issue date, not Subscription start date
Summary: Serials: Test prediction pattern starts at First issue date, not Subscription...
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: Serials (show other bugs)
Version: master
Hardware: All All
: P5 - low normal with 8 votes (vote)
Assignee: Nick Clemens
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-06 11:55 UTC by Mirko Tietgen
Modified: 2021-02-06 16:12 UTC (History)
11 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 15148: Predict serials issues from subscription start date (5.14 KB, patch)
2019-01-23 01:03 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 15148: Predict serials issues from subscription start date (5.00 KB, patch)
2019-07-01 12:15 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 15148: Make param order more logical (1.30 KB, patch)
2019-07-01 12:18 UTC, Nick Clemens
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Mirko Tietgen 2015-11-06 11:55:29 UTC
To reproduce: add or edit a serial, Set dates for
First issue,
Subscription length
Subscripton start

Test prediction pattern. You will get a list with the number of issues matching 'subscription length' value, but starting from First issue date, not Subscription start date.

Expected: use subscription start and end date to determine the range of issues to show in prediction.
Comment 1 Nick Clemens 2019-01-23 01:03:48 UTC
Created attachment 84312 [details] [review]
Bug 15148: Predict serials issues from subscription start date

To test:
1 - Create a new serial
2 - Set 'First issue plublication date' to some date in 2016
3 - Set subscription start date to today
4 - Set length to 104 weeks
5 - Test prediction pattern - only one generated
6 - Apply patch
7 - Test prediction patern - many generated!
Comment 2 José-Mario Monteiro-Santos 2019-01-25 19:52:55 UTC
Patch failed to apply

Applying: Bug 15148: Predict serials issues from subscription start date
Using index info to reconstruct a base tree...
M	koha-tmpl/intranet-tmpl/prog/js/subscription-add.js
M	serials/showpredictionpattern.pl
Falling back to patching base and 3-way merge...
Auto-merging serials/showpredictionpattern.pl
Auto-merging koha-tmpl/intranet-tmpl/prog/js/subscription-add.js
CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/js/subscription-add.js
error: Failed to merge in the changes.
Patch failed at 0001 Bug 15148: Predict serials issues from subscription start date


Also, are you sure step 5 of your test plan is correct ? When I did it, I had all 104 results in the prediction. The problem is that the issues' dates start in 2016 (first publication) instead of 2019 (subscription start)
Comment 3 Fridolin Somers 2019-02-21 16:21:12 UTC
I think in JS "from" should be before the "to". They mean start and end dates.

During test plan, you may refresh browser cache (Ctrl+F5) after applying patch to refresh JavaScript file.
Comment 4 Nick Clemens 2019-07-01 12:15:21 UTC
Created attachment 91141 [details] [review]
Bug 15148: Predict serials issues from subscription start date

To test:
1 - Create a new serial
2 - Set 'First issue plublication date' to some date in 2016
3 - Set subscription start date to today
4 - Set length to 104 weeks
5 - Test prediction pattern - only one generated
6 - Apply patch
7 - Test prediction patern - many generated!
Comment 5 Nick Clemens 2019-07-01 12:18:40 UTC
Created attachment 91142 [details] [review]
Bug 15148: Make param order more logical
Comment 6 Katrin Fischer 2019-07-01 12:20:32 UTC
Hm, I am not sure this is right.

We always say that the date of the first issue matters, so if you set that to 15th and the subscription start date to 1st, the pattern should still use the 15th for calculating. That's how it always worked, it looks like this might change that?
Comment 7 Myka Kennedy Stephens 2019-10-18 20:12:37 UTC
Patch does not apply.

Here is the behavior I'm seeing in my test:

On master, without the patches from this bug applied:
1. Create a new serial subscription
2. Set the first publication date to a date in 2016
3. Set the subscription start date to a recent date in 2019
4. Set subscription length to 104 issues
** Also set frequency to weekly, numbering pattern to number beginning with number 1
5. Test prediction pattern
** This results in a pattern that is for numbers 1-104 beginning with the date of the first issue. The subscription start date is not included in the predictions listed because it is beyond the 104 issues.
6. Apply patch
* Repeat steps 1-5
7. Test prediction pattern
** The results match the prediction pattern prior to applying the patch. When you save the subscription, the issue expected is Issue No. 1 from 2016, not the issue that corresponds with the subscription start date.

The expected/desired behavior is for Koha to start the prediction pattern based on the subscription start date, listing the number of issues based on the subscription length value. Koha will need to calculate the issue number based on the numbering pattern and the first issue publication date. 

What is presently happening is the prediction pattern is based on the first date of publication and length of subscription. This is a problem for libraries that start a new subscription in the middle of a publication, need to predict issues from the starting point of their subscription, and want to preserve the first date of publication in Koha.
Comment 8 Fridolin Somers 2020-01-07 10:32:07 UTC
Look at serials/subscription-add.pl _guess_enddate() :

        } elsif($frequency->{'unit'} eq 'month') {
            ($year, $month, $day) = Add_Delta_YM(split(/-/, $startdate_iso), 0, $numberlength * $frequency->{'unitsperissue'} / $frequency->{'issuesperunit'});

It is called by :

        if($subtype eq "issues") {
            $enddate = _guess_enddate($firstacquidate, $periodicity, $numberlength, $weeklength, $monthlength)
        } else {
            $enddate = _guess_enddate($startdate, $periodicity, $numberlength, $weeklength, $monthlength)
        }

You see subscription start date is used.
Comment 9 Katrin Fischer 2020-03-15 23:07:42 UTC
Hi Myka, 

I think there might be some possible misunderstanding there:

>The expected/desired behavior is for Koha to start the prediction pattern based on the subscription start date, listing the number of issues based on the subscription length value. Koha will need to calculate the issue number based on the numbering pattern and the first issue publication date. 

>What is presently happening is the prediction pattern is based on the first date of publication and length of subscription. This is a problem for libraries that start a new subscription in the middle of a publication, need to predict issues from the starting point of their subscription, and want to preserve the first date of publication in Koha.

In Koha, it was always documented: "In ‘First issue publication date’ you want to enter the date of the issue you have in your hand, the date from which the prediction pattern will start". See: https://koha-community.org/manual/19.11/en/html/serials.html?highlight=first%20publication

So I wonder how changing that would affect libraries already using subscriptions for a long time. At the moment, it could look something like this for a lot of libraries:

Subscription start date: January 1st
First issue publication: March 15th (the first issue that was tracked when starting to use the serials module)

It's possible to start in the middle of a prediction pattern - if you give me an example that you are not sure about, I'd be happy to help and see if we can make it work.
Comment 10 Nick Clemens 2020-03-16 10:50:58 UTC
I think the issue here has been for bringing in subscriptions from another system, so you are setting the first issue to the first one held, but then adding the start date and wanting to see the issues from that date forward?

Either way, maybe a better solution is to preserve existing behaviour and add an option (radio button) to select generating from the sub start date instead of first issue?
Comment 11 Katrin Fischer 2020-03-16 18:58:11 UTC
(In reply to Nick Clemens from comment #10)
> I think the issue here has been for bringing in subscriptions from another
> system, so you are setting the first issue to the first one held, but then
> adding the start date and wanting to see the issues from that date forward?
> 
> Either way, maybe a better solution is to preserve existing behaviour and
> add an option (radio button) to select generating from the sub start date
> instead of first issue?

Sounds good to me! I'd also be interested in being able to compare to understand the differences pointed out here better
Comment 12 Myka Kennedy Stephens 2020-05-06 23:22:03 UTC
I like Nick's solution. Give the user a choice (radio button) to generate issues based on date of first issue or subscription date.

Scenario: A library acquires a run of a serial that started in 2000. The back issues are already bound together and ready to be added as items. The library also starts a subscription to continue receiving new items beginning on January 1, 2020. The library wants to preserve the information that the first issue was published on January 1, 2000 but the predicted issues only need to be generated from January 1, 2020 and on.

In this scenario, it makes more sense to base a prediction on the subscription start instead of the date of first issue. Our library workflow would use acquisitions or simply add the back issues as items to the biblio instead of receiving them through the serials module -- especially if they were already bound together as volumes. 

(I'm also going to change the status to 'failed QA' since I incorrectly used 'patch doesn't apply' when I tested this back in October.)
Comment 13 Katrin Fischer 2021-02-06 16:12:34 UTC
Rereading this I wondered:

Maybe we should keep the first issue as is, but rename it "Start issue" or similar and have a new and different field, perhaps linked to subscription history, for the first issue published/available in the library if there is a need for having this information? 

My use case was this:

The subscription start date could have been at the beginning of the year or even years ago (most here are renewed automatically) and I don't really care about this date for the predictions.

The "Start issue" would be the one I start predicting with.

The "historical" first issue  would be the first one in my library's collection.

... and now I wonder if this isn't what the subscription history fields are already supposed to be used for:

- Check manual history
- Go to the subscription
- Edit the manual history
- Change the subscription start date.

It won't change the start date when editing the subscription, as these fields are all stored separately in the database. So maybe the solution is ultimately to make the history more accessible and maybe add any additionally needed information there?