If the end date is not set we should not set it to today.
On bug 30718 the following change was wrong:
-$enddate = eval { output_pref( { str => $enddate, dateonly => 1, dateformat => 'iso' } ); };
+$enddate = dt_from_string($enddate)->ymd;
output_pref returns undef if str is empty
After the change we returned today's date.
Test plan:
1. Go to Serials > Manage numbering patterns
2. Click Edit next to one of the existing patterns (e.g. Number)
3. Enter information in the Test prediction pattern section
- Frequency: choose one (e.g. 1/month)
- First issue publication date: enter a date (e.g. 2023-06-01)
- Subscription length: issues + enter a number of issues (e.g. 12)
- Locale: leave empty
- Begins with: enter a number in the X column, e.g. 42
4. Click Test pattern
=> Without this patch only one issue is shown, no matter how many you enter in Subscription length
=> With this patch applied the end date is not set to today and the
prediction pattern list is correct
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit c9a2cf948d)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Can't locate object method "ymd" via package "2022-02-01" (perhaps you forgot to load "2022-02-01"?) at /kohadevbox/koha/serials/showpredictionpattern.pl line 100
eval {...} at /kohadevbox/koha/serials/showpredictionpattern.pl line 2
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The idea rely on the KohaDates TT plugin for the date formatting. We
should not have any output_pref calls in pl or pm (there are some
exceptions, for ILSDI for instance).
Also flatpickr will deal with the places where dates are inputed. We
will pass the raw SQL value (what we call 'iso' in Koha::DateUtils), and
the controller will receive the same value, no need to additional
conversion.
Note that DBIC has the capability to auto-deflate DateTime objects,
which makes things way easier. We can either pass the value we receive
from the controller, or pass a DT object to our methods.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It defaults to 0 in get_template_and_user
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To reproduce:
1) add a serial.
2) set first issue = today
3) set frequency = 1/month
4) dont set subscription length
5) set subscription start date = today
6) set subscription start date = today + 1 year
7) set numbering pattern = Number
8) test prediction pattern.
=> Without patch : you will get a list of 1000 issues, going well beyond subscripton end date.
=> With patch : shows only the issues within the date range.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: zhihui <zhihui@inlibro.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
- 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>
Warning: This area is a mess, especially with date management.
For the same reasons as other "Remove C4::Dates from*" patches, this one
will deal with the serials module.
Note that this patch add the datepicker on 3 input fields (on
serials/subscription-detail.tt and serials/subscription-renew.tt).
There was also weird behavior when the dates were invalid. Now default
to undefined. But with the datepicker it will reduce the number of
cases even if the user is still allowed to fill invalid dates.
Test plan:
1/ Create a subscription, fill the first issue pub date and the
subscription start date.
You can fill or not the end date.
Play with the numbering pattern and confirm that there are generated as
before this patch.
2/ On the check expiration page, confirm that the dates are correctly
displayed.
3/ Renew the subscription and confirm that the behavior is correct.
4/ Go on the subscription history page and confirm you have now the
datepicker plugin set on the 2 date fields.
QA notes: The startdate, histstartdate and enddate are not used in
the serials-collection template, this patch removes them from the pl
script.
Tested on top of 15166 15168 15171, full browser reload for date pickers.
Note for 4/: It is the link in tab planning on subscription
detail page, near "Manual history" (if manual history is enabled).
Works as advertised.
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>
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>
Test plan:
Create a subscription with an irregular numbering pattern.
Verify the prediction pattern. With this patch, it should show "unknown"
instead of the date of the first issue publication date.
This patch does not fix the issue on generating the next serial.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
This is a partial fix for a small regression in the serials module.
Now the prediction pattern doesn't predict dates when you test it,
and shows 'Unknown' instead.
We still need to fix the 'planned date' set for the expected serial.
There should be no date, it should also be 'unknown'.
Passes tests and QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Serials numbering pattern and frequencies are no longer hard-coded. Now
it's possible to create, edit and delete numbering patterns (and
frequencies). This patch adds two new sql tables
(subscription_numberpatterns and subscription_frequencies)
Numbering patterns behave almost as before, there are still the same
values to configure (addX, everyX, settoX, whenmorethanX). lastvalueX
and innerloopX remain in subscription tables.
There is a new value in numbering patterns: numberingX. For each
"column" (X, Y or Z) you can tell how to format the number. Actually
numberingX can be set to:
- 'dayname' (name of the day) (0-6 or 1-7 depending on which day is the
first of the week)
- 'monthname' (name of the month) (0-11)
- 'season' (name of the season) (0-3) (0 is Spring)
These names are localized by using POSIX::setlocale and POSIX::strftime
and setting a 'locale' value to the subscription. Locale have to be
installed on the system.
Note that season names are not localized using POSIX::strftime (it can't
do this), so names are hardcoded into the code (available languages: en,
fr). This could be fixed in the future by using a Perl localization
framework.
Frequencies can be configured using 3 parameters:
- 'unit': one of 'day', 'week', 'month', 'year'
- 'issuesperunit': integer >= 1, the number of received issues per
'unit'
- 'unitsperissue': integer >= 1, the number of 'unit' between two
issues
One of 'issuesperunit' and 'unitsperissue' must be equal to 1.
Examples:
unit = 'day', issuesperunit=3, unitsperissue=1 => 3 issues per day
unit = 'week', issuesperunit=1, unitsperissue=3 => 1 issue each 3
weeks
Prediction pattern is now computed server-side and is more consistent
with what Koha will do. The publication date is displayed alongside the
serial number.
Irregularities can now be checked one by one, in the prediction pattern
table, or if frequency is 'day-based' (unit is 'day'), there is the
possibility to check all issues for a week day at once.
When an irregularity is found, there is the possibility to keep the
serial number unchanged, or to skip it. It is configured at subscription
creation or modification.
For instance, with a daily subscription you can have:
skip serial number | keep serial number
----------------------+----------------------
2012-01-01 ¦ No 1 | 2012-01-01 ¦ No 1
2012-01-03 ¦ No 3 | 2012-01-03 ¦ No 2
To lighten the subscription modification page, manual history has been
moved in its own page subscription-history.pl which is accessible on
subscription-detail.pl, tab 'Planning'.
Important note: updatedatabase.pl script takes into account existing
subscriptions and create appropriate numbering patterns for them (it
tries to create as few patterns as possible). Frequency is
mapped to the correct entry in subscription_frequencies table.
This patch includes kohastructure.sql and updatedatabase.pl changes
+ sample frequencies data and sample numberpatterns data for fresh
installs (sample data is included in updatedatabase.pl)
=== TEST PLAN: ===
Create a new subscription:
- Go to Serials module and click "New subscription" button
- On the first page, choose a biblio and click next to go to the
second page
- Pick a first issue publication date
- Choose frequency '1/day'
- Choose a subscription length of 15 issues
- Choose a subscription start date
- Choose numbering pattern 'Volume, Number'
- A table appears, fill 'Begins with' cells with '1'
- Click on 'Test prediction pattern' button
The prediction pattern is displayed at the right of the page. You can
see in it the serial number, the publication date and a checkbox to
allow you to choose which serials will not be received (irregularities).
You can see that serial number start from "Vol 1, No 1" continue to "Vol
1, No 12" and then restart with "Vol 2, No 1".
Frequency is '1/day' so you can see that publication date is incremented
by one day line after line.
- Now you can play a little with frequencies and numbering patterns,
change one of them (or both) and click again on 'Test prediction
pattern'
- For example, choose frequency '3/weeks' and click on 'Test
prediction pattern' button'.
There is a little behaviour change compared with current master.
Publication date will not be guessed within the week. Koha can't know
when you will receive issues. So the publication date stay the same
(monday of each week) for 3 consecutive issues and then jump to the next
week.
- Now choose frequency '1/3 months' and numbering pattern 'Seasonal'
- Fill 'Begins with' cells with '2012' for Year and '0' for Season
- Click on 'Test prediction pattern'
- You should have something like 'Spring 2012', 'Summer 2012', ...,
'Winter 2012', 'Spring 2013'
- Note that you can have seasons for south hemisphere by entering '2'
in 'Year/Inner counter'
- 2nd note: if you have some locales installed on your system, you can
type its name in the 'Locale' field (actually it does not work for
seasons name, only for month names and day names)
If you want to modify the numbering pattern you can still do it here:
- Click on 'Show/Hide advanced pattern' link. The advanced pattern
table is shown but all fields are readonly
- Click on 'Modify pattern' button. All readonly fields are now
editable. Note that 'Begins with' and 'Inner counter' line are
repeated here and any modifications in the small table will be
replicated in the big table, and vice versa.
- Pattern name is emptied, if you type a new name, a new pattern will
be created, and if you type the same name as an existing numbering
pattern, this one will be modified (with a confirmation message)
- There is two new lines in this table:
- Label: it's what is displayed in the smaller table headers above
- Numbering: used to format numbers in different ways. can be
'seasons', 'monthname' or 'dayname'. Month name and day name can be
localized using the 'Locale' field. Seasons can't (values for
English and french are hard-coded in Serials.pm)
- You can modify what you want in the table and click on 'Test
prediction pattern' button each time you want to see your
modifications. (Note that checkboxes for irregularities aren't displayed
in this mode, and you can't save the subscription until you have saved
or cancelled your changes).
- To cancel your modifications, just click on 'Cancel modifications'
button.
- To save them, click on 'Save as new pattern'. If the pattern name is
already existing, a confirmation box will ask you if you want to
modify the existing numbering pattern. Otherwise a new pattern will be
created and automatically selected.
Once you have finished modifying numbering pattern, you can click again
on 'Test prediction pattern' to define irregularities, and then click on
'Save subscription'.
Now you can check the serials module still works correctly:
- Check the subscription detail page to confirm that nothing is
missing. Especially the 'Frequency' and 'Number pattern' information.
- Try to receive some issues. Check that the serial number is correctly
generated and if irregularities you have defined are taken into
account (if you have defined some).
- Check that receiving is blocked once you have reached the number of
issues you have defined in subscription length (or once you have
reached the subscription end date)
In serials menu (to the left of almost each page of serials menu) you
have two new links: 'Manage frequencies' and 'Manage numbering
patterns'.
'Manage numbering patterns' lead to a page which list all numbering
patterns and allow you to create, edit or delete them. The interface is
almost the same as numbering pattern modification in subscription-add.pl
'Manage frequencies' lead to a page which list all frequencies and allow
you to create, edit or delete them.
Try to create a new frequency:
- Click on 'Manage frequencies' link in the serials menu and then click
on 'New frequency':
- Fill in the description (mandatory).
- Unit is one of 'day', 'week', 'month', year' or 'None' ('None' is for
an irregular subscription)
- If unit is different from 'None' you have to fill the two following
fields (Issues per unit, and Units per issue)
- Note that at least one of those must be equal to 1
- Issues per unit is the number of received issues by 'unit' and Units
per issue is the number of 'unit' between two issues
- Display order is used to build the drop-down list. Leave empty and it
will be set to 0 (top of the list)
- Then click on 'Save'
- Check that this new frequency appears in the frequencies table and in
the drop-down list in subscription-add.pl
Subscription history has been moved in its own page. To test if it still
works, choose a subscription with manual history enabled (or modify an
existing subscription to turn on manual history).
- On the detail page, tab 'Planning', you should have a link 'Edit history'.
- Click on it
- Modify history and click on Save
- In tab 'Summary' you should have the infos you just entered
And finally, you can check that old subscriptions (by old I mean
subscriptions that existed before the update) are correctly linked to an
existing numbering pattern and an existing frequency. Numbering patterns
should be named 'Backup pattern X' where X is a number.
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Great development! Work as described. No koha-qa errors
(with all patches applied). Please QA this fast.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Squashed commits:
-----------------
Bug 7688 follow-up: Small fixes for QA
- # Subroutines::ProhibitExplicitReturnUndef: Got 1 violation(s) in
C4::Serials::GetSubscriptionIrregularities
- Bad template constructions fixed in serials/subscription-add.tt
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
----
Bug 7688 follow-up: Small fixes for QA #2
- "return undef" -> "return"
- ":utf8" -> ":encoding(UTF-8)"
- TAB -> SPACES
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
----
Bug 7688: Translate sample frequencies for french
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
----
Bug 7688: Fix generating next serial when there is no 'Expected' issue
It can happen when the Expected issue is claimed. In this case the
status of the last serial is 'Claimed'
This patch change the API of GetNextSeq and GetSeq
Test plan:
- Create a subscription which starts a long time ago so that serials
automatically appear in late issues
- Receive the first serial
- Go to claims page and claim the 2nd serial.
- Go back to the subscription page and click on 'Serial collection'
- You should have 2 serials, one 'Arrived' and one 'Claimed'.
- Click on Generate Next. This should fail with a software error message
("can't call method output ...")
- Apply this patch and click again on Generate Next. A new issue must be
created with status 'Expected'.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
----
Bug 7688: Followup FIX perldoc
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This reverts commit 60508cb03d, reversing
changes made to 8579d07f14.
The patches for bug 7688 caused a failure in t/db_dependent/Serials.t:
not ok 8 - test getting history from sub-scription
Conflicts:
installer/data/mysql/kohastructure.sql
installer/data/mysql/updatedatabase.pl
kohaversion.pl
It can happen when the Expected issue is claimed. In this case the
status of the last serial is 'Claimed'
This patch change the API of GetNextSeq and GetSeq
Test plan:
- Create a subscription which starts a long time ago so that serials
automatically appear in late issues
- Receive the first serial
- Go to claims page and claim the 2nd serial.
- Go back to the subscription page and click on 'Serial collection'
- You should have 2 serials, one 'Arrived' and one 'Claimed'.
- Click on Generate Next. This should fail with a software error message
("can't call method output ...")
- Apply this patch and click again on Generate Next. A new issue must be
created with status 'Expected'.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Serials numbering pattern and frequencies are no more hard-coded. Now
it's possible to create, edit and delete numbering patterns (and
frequencies). This implies new sql tables (subscription_numberpatterns
and subscription_frequencies)
Numbering patterns behave almost as before, there are still the same
values to configure (addX, everyX, settoX, whenmorethanX). lastvalueX
and innerloopX remain in subscription tables.
There is a new value in numbering patterns: numberingX. For each
"column" (X, Y or Z) you can tell how to format the number. Actually
numberingX can be set to:
- 'dayname' (name of the day) (0-6 or 1-7 depending on which day is the
first of the week)
- 'monthname' (name of the month) (0-11)
- 'season' (name of the season) (0-3) (0 is Spring)
These names are localized by using POSIX::setlocale and POSIX::strftime
and setting a 'locale' value to the subscription. Locale have to be
installed on the system.
Note that season names are not localized using POSIX::strftime (it can't
do this), so names are hardcoded into the code (available languages: en,
fr). This could be fixed in the future by using a Perl localization
framework.
Frequencies can be configured using 3 parameters:
- 'unit': one of 'day', 'week', 'month', 'year'
- 'issuesperunit': integer >= 1, the number of received issues per
'unit'
- 'unitsperissue': integer >= 1, the number of 'unit' between two
issues
One of 'issuesperunit' and 'unitsperissue' must be equal to 1.
Examples:
unit = 'day', issuesperunit=3, unitsperissue=1 => 3 issues per day
unit = 'week', issuesperunit=1, unitsperissue=3 => 1 issue each 3
weeks
Prediction pattern is now computed server-side and is more consistent
with what Koha will do. The publication date is displayed alongside the
serial number.
Irregularities can now be checked one by one, in the prediction pattern
table, or if frequency is 'day-based' (unit is 'day'), there is the
possibility to check all issues for a week day at once.
When an irregularity is found, there is the possibility to keep the
serial number unchanged, or to skip it. It is configured at subscription
creation or modification.
For instance, with a daily subscription you can have:
skip serial number | keep serial number
----------------------+----------------------
2012-01-01 ¦ No 1 | 2012-01-01 ¦ No 1
2012-01-03 ¦ No 3 | 2012-01-03 ¦ No 2
To lighten the subscription modification page, manual history has been
moved in its own page subscription-history.pl which is accessible on
subscription-detail.pl, tab 'Planning'.
Important note: updatedatabase.pl script takes into account existing
subscriptions and create appropriate numbering patterns for them (it
tries to create as few patterns as possible). Frequency is
mapped to the correct entry in subscription_frequencies table.
This patch includes kohastructure.sql and updatedatabase.pl changes
+ sample frequencies data and sample numberpatterns data for fresh
installs (sample data is included in updatedatabase.pl)
=== TEST PLAN: ===
Create a new subscription:
- Go to Serials module and click "New subscription" button
- On the first page, choose a biblio and click next to go to the
second page
- Pick a first issue publication date
- Choose frequency '1/day'
- Choose a subscription length of 15 issues
- Choose a subscription start date
- Choose numbering pattern 'Volume, Number'
- A table appears, fill 'Begins with' cells with '1'
- Click on 'Test prediction pattern' button
The prediction pattern is displayed at the right of the page. You can
see in it the serial number, the publication date and a checkbox to
allow you to choose which serials will not be received (irregularities).
You can see that serial number start from "Vol 1, No 1" continue to "Vol
1, No 12" and then restart with "Vol 2, No 1".
Frequency is '1/day' so you can see that publication date is incremented
by one day line after line.
- Now you can play a little with frequencies and numbering patterns,
change one of them (or both) and click again on 'Test prediction
pattern'
- For example, choose frequency '3/weeks' and click on 'Test
prediction pattern' button'.
There is a little behaviour change compared with current master.
Publication date will not be guessed within the week. Koha can't know
when you will receive issues. So the publication date stay the same
(monday of each week) for 3 consecutive issues and then jump to the next
week.
- Now choose frequency '1/3 months' and numbering pattern 'Seasonal'
- Fill 'Begins with' cells with '2012' for Year and '0' for Season
- Click on 'Test prediction pattern'
- You should have something like 'Spring 2012', 'Summer 2012', ...,
'Winter 2012', 'Spring 2013'
- Note that you can have seasons for south hemisphere by entering '2'
in 'Year/Inner counter'
- 2nd note: if you have some locales installed on your system, you can
type its name in the 'Locale' field (actually it does not work for
seasons name, only for month names and day names)
If you want to modify the numbering pattern you can still do it here:
- Click on 'Show/Hide advanced pattern' link. The advanced pattern
table is shown but all fields are readonly
- Click on 'Modify pattern' button. All readonly fields are now
editable. Note that 'Begins with' and 'Inner counter' line are
repeated here and any modifications in the small table will be
replicated in the big table, and vice versa.
- Pattern name is emptied, if you type a new name, a new pattern will
be created, and if you type the same name as an existing numbering
pattern, this one will be modified (with a confirmation message)
- There is two new lines in this table:
- Label: it's what is displayed in the smaller table headers above
- Numbering: used to format numbers in different ways. can be
'seasons', 'monthname' or 'dayname'. Month name and day name can be
localized using the 'Locale' field. Seasons can't (values for
english and french are hard-coded in Serials.pm)
- You can modify what you want in the table and click on 'Test
prediction pattern' button each time you want to see your
modifications. (Note that checkboxes for irregularities aren't displayed
in this mode, and you can't save the subscription until you have saved
or cancelled your changes).
- To cancel your modifications, just click on 'Cancel modifications'
button.
- To save them, click on 'Save as new pattern'. If the pattern name is
already existing, a confirmation box will ask you if you want to
modify the existing numbering pattern. Otherwise a new pattern will be
created and automatically selected.
Once you have finished modifying numbering pattern. You can click again
on 'Test prediction pattern' to define irregularities, and then click on
'Save subscription'.
Now you can check the serials module still works correctly:
- Check the subscription detail page to confirm that nothing is
missing. Especially the 'Frequency' and 'Number pattern' infos
- Try to receive some issues. Check that the serial number is correctly
generated and if irregularities you have defined are taken into
account (if you have defined some).
- Check that receiving is blocked once you have reached the number of
issues you have defined in subscription length (or once you have
reached the subscription end date)
In serials menu (to the left of almost each page of serials menu) you
have two new links: 'Manage frequencies' and 'Manage numbering
patterns'.
'Manage numbering patterns' lead to a page which list all numbering
patterns and allow you to create, edit or delete them. The interface is
almost the same as numbering pattern modification in subscription-add.pl
'Manage frequencies' lead to a page which list all frequencies and allow
you to create, edit or delete them.
Try to create a new frequency:
- Click on 'Manage frequencies' link in the serials menu and then click
on 'New frequency':
- Fill in the description (mandatory).
- Unit is one of 'day', 'week', 'month', year' or 'None' ('None' is for
an irregular subscription)
- If unit is different from 'None' you have to fill the two following
fields (Issues per unit, and Units per issue)
- Note that at least one of those must be equal to 1
- Issues per unit is the number of received issues by 'unit' and Units
per issue is the number of 'unit' between two issues
- Display order is used to build the drop-down list. Leave empty and it
will be set to 0 (top of the list)
- Then click on 'Save'
- Check that this new frequency appears in the frequencies table and in
the drop-down list in subscription-add.pl
Subscription history has been moved in its own page. To test if it still
works, choose a subscription with manual history enabled (or modify an
existing subscription to turn on manual history).
- On the detail page, tab 'Planning', you should have a link 'Edit history'.
- Click on it
- Modify history and click on Save
- In tab 'Summary' you should have the infos you just entered
And finally, you can check that old subscriptions (by old I mean
subscriptions that existed before the update) are correctly linked to an
existing numbering pattern and an existing frequency. Numbering patterns
should be named 'Backup pattern X' where X is a number.
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Great development! Work as described. No koha-qa errors
(with all patches applied). Please QA this fast.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Julian Maurice
morgane alonso
Jonathan Druart
Galen Charlton
Jared Camins-Esakov
