Summary: | Change of issue publication date doesn't reflect on the next issue generated | ||
---|---|---|---|
Product: | Koha | Reporter: | Francois Charbonnier <francois.charbonnier> |
Component: | Serials | Assignee: | Bouzid Fergani <bouzid.fergani> |
Status: | RESOLVED DUPLICATE | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | bouzid.fergani, caroline.cyr-la-rose, colin.campbell, gaetan.boisson, julian.maurice, m.de.rooy, philippe.blouin |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Bug Depends on: | 12671 | ||
Bug Blocks: | |||
Attachments: |
Bug 16116 - Fix problem change of issue publication date doesn't reflect on the next issue generated
Bug 16116 - Add unit tests Bug 16116 - Fix problem change of issue publication date doesn't reflect on the next issue generated [SIGNED-OFF] Bug 16116 - Fix problem change of issue publication date doesn't reflect on the next issue generated |
Description
Francois Charbonnier
2016-03-21 20:21:45 UTC
Could it be https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12671 (Guess next serial date when there are several issues per unit) that broke this feature? Confirmed. I was not able to change the next issue date in a durable fashion. This might be a bigger problem than it seems, because in certain situations (a "double issue" that skips a month, that is number 36 is for February and march, and number 37 is for April) this is the recommended way of handling it. I haven't tested this toroughly yet. Maybe the number guessing method makes sure we don't get two issues for April, but there would be a lot of edge cases to try. (In reply to Francois Charbonnier from comment #1) > Could it > be https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12671 (Guess > next serial date when there are several issues per unit) that > broke this feature? Probably. I just looked at the code quickly and I think the problem comes from the _get_next_date_* subroutines where we force the day (or day and month) to the same as firstacquidate. Maybe it's not necessary. Created attachment 58265 [details] [review] Bug 16116 - Fix problem change of issue publication date doesn't reflect on the next issue generated Test plan : 1. In Cataloging > New with Z39.50, look for issn = 1536-6596 (National Geographic) into the LCC z39.60 server. Add the record. 2. Add a new subscription for National Geographic. Fill-in the form. - use the default values of the first page - for the second page : First issue publication date = 10/01/2016 Frequency = 1/month Subscription lenght = 12 issues Subscription start date = 01/01/2016 Numbering pattern = Number Begins with = 1 - Save 3. Receive the first issue. Change the status to "received". Note that the "Published on" date = 10/01/2016. This date goes to the "Date published" column in the serial collection page. 4. The second issue is generated. Edit serial to receive the issue. 5. Change the "Published on" date to 14/02/2016. Change the status to "received". Save. 6. "Date published" for the next issue generated is : 14/03/2016. Created attachment 58266 [details] [review] Bug 16116 - Add unit tests Created attachment 61002 [details] [review] Bug 16116 - Fix problem change of issue publication date doesn't reflect on the next issue generated Test plan : 1. In Cataloging > New with Z39.50, look for issn = 1536-6596 (National Geographic) into the LCC z39.60 server. Add the record. 2. Add a new subscription for National Geographic. Fill-in the form. - use the default values of the first page - for the second page : First issue publication date = 10/01/2016 Frequency = 1/month Subscription lenght = 12 issues Subscription start date = 01/01/2016 Numbering pattern = Number Begins with = 1 - Save 3. Receive the first issue. Change the status to "received". Note that the "Published on" date = 10/01/2016. This date goes to the "Date published" column in the serial collection page. 4. The second issue is generated. Edit serial to receive the issue. 5. Change the "Published on" date to 14/02/2016. Change the status to "received". Save. 6. "Date published" for the next issue generated is : 14/03/2016. Hi All, I deteted patch unit test because it test a local sub. Thanks Created attachment 62163 [details] [review] [SIGNED-OFF] Bug 16116 - Fix problem change of issue publication date doesn't reflect on the next issue generated Test plan : 1. In Cataloging > New with Z39.50, look for issn = 1536-6596 (National Geographic) into the LCC z39.60 server. Add the record. 2. Add a new subscription for National Geographic. Fill-in the form. - use the default values of the first page - for the second page : First issue publication date = 10/01/2016 Frequency = 1/month Subscription lenght = 12 issues Subscription start date = 01/01/2016 Numbering pattern = Number Begins with = 1 - Save 3. Receive the first issue. Change the status to "received". Note that the "Published on" date = 10/01/2016. This date goes to the "Date published" column in the serial collection page. 4. The second issue is generated. Edit serial to receive the issue. 5. Change the "Published on" date to 14/02/2016. Change the status to "received". Save. 6. "Date published" for the next issue generated is : 14/03/2016. Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Would it be possible for Francois, Gaetan or Julian to test this patch too?
I am not so sure if the proposed changes really solve all problems in this area.
Another signoff would not be a bad idea.
Another point (referring to an earlier remark):
> Before 3.20, when receiving a new issue, you could change the "Published on"
> date and Koha will adjust the subscription's next issue publication date for
> all the new issues to be received.
Would it be an idea to add an option to the subscription that makes it possible to rebase issue dates somehow ? We now have a 'buggy' mix of using last issue and first acqui date. Maybe an additional base date to use optionally (overruling first acqui)? Other ideas ?
Moving this patch out of the SO queue for now. This should not be pushed in its current form just before release. Hi Marcel, can this go back into the queue now? I am currently trying to figure out a way for the library to change the date an issue is published and am failing... I think this really needs a solution. (In reply to Katrin Fischer from comment #11) > Hi Marcel, can this go back into the queue now? > > I am currently trying to figure out a way for the library to change the date > an issue is published and am failing... I think this really needs a solution. I have spent some more time on this problem. Please look at bug 18356, bug 18607 and bug 18697. That solution also includes releasing the link with firstacqui date and solves several computational problems. It is imo a completer solution and supported by tests. For that reason I would propose to close this bug if these patches have been QAed. *** This bug has been marked as a duplicate of bug 18356 *** |