Includes:
* code factorization
Some code from subscription & Mana-KB has been factorized in order to speed-up next developments
* SytemPreferences:
Mana Activation:
- add a value "no, let me think about it", that is the default value.
- as long as this value is selected, messages ask if user want to activate it ( in Administration and Add-subscription(page 2) )
AutoShareWithMana
- Add the syspref AutoShareWithMana: user can automatically share infos with Mana-KB (not set by default)
* Interface :
- On mana-search, rows are now sorted by date of last import, then by number of users
- Windows redesigned to improve the user experience
* New Feature : report a mistake.
- people can now report an invalid data (wrong, obsolete,...)
- if a data is reported as invalid many time, it will appear differently
- Added few tooltip (to explain the fields last import, nb of users, to explain the new feature)
- When reporting a data as invalid, a comment can also be added. Koha will then display comments related to data in result lists
* API (svc/mana)
- add svc/mana/addvaluetofield: allows to ask mana incrementing a field of a resource
- no hardcoding for resources in the code of api (api needs to be called with a ressourcename)
* New feature : SQL report sharing
- Create Koha::Report.pm and Koha::Reports.pm, objects class for Reports
- New feature: share reports with Mana-KB
- New feature: search report in Mana-KB with keywords
- New feature: load reports from Mana-KB
Test plan:
1 - Apply Patch + update database
2 - Copy the three lines about mana config in etc/koha-conf.xml in ../etc/koha-conf.xml (after <backupdir> for example)
<!-- URL of the mana KB server -->
<!-- alternative value http://mana-test.koha-community.org to query the test server -->
<mana_config>https://mana-kb.koha-community.org</mana_config>
3 - Check Mana syspref and AutoShareWithMana syspref are not activated
4 - Search the syspref ManaToken and follow the instructions
5 - subscriptions
- Try create a new subscription for a first serial => Mana-KB shouldn't show you anything (except if the base hase been filled)
- Share this serial with Mana-KB (on the serial individual's page there must be a Share button)
- Try to create a new subscription for serial nr1 => a message should appear when you click on "next", click on "use", the fields should automaticaly appear
- Activate AutoShareWithMana => Subscriptions
- Create a new subscription for a second serial
- There shouldn't be any Share button
- Create a second subscription => the message should appear, click again on use
6 - SQL Report
- Create a new SQL report, without notes.
- On the table with all report (reports > use saved), there should be the action "Share"
- If you click on share, you have an error message
- Create a new report, with a title and notes longer than 20 characters
- You can share it with mana => you will have a success message
- On (report > use saved), there must be a message inviting you to search on Mana-KB for more results, enter a few word from title, notes, type of the report you shared, it should appear. You can use it, it will load it into your report list.
7 - Report mistakes.
- On any table containing Mana-KB search results, you can report a mistake and add a comment.
8 - For each previous test, try to send wrong data, to delete the security token, to send nothing: it should show a correct warning message.
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>
- 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>
The idea of output_and_exit_if_error (added by bug 18403) is to make sure
parameters are valid before executing the script.
If not (old or broken URLs), we shortcut everything coming next to display a
generic error ("object does not exist", "you do not have permission to do that", etc.)
This bug report fixes the scripts under serials/*.
Test plan:
Hit the script under the serials directory with an invalid subscriptionid parameter
and confirm you get an error instead of the normal view with empty values.
The goal is not to be exhaustive during the first iteration, but at least to fix
the most common views.
For instance:
/cgi-bin/koha/serials/subscription-detail.pl?subscriptionid=XXX
/cgi-bin/koha/serials/serials-collection.pl?subscriptionid=XXX
/cgi-bin/koha/serials/routing.pl?subscriptionid=XXX&op=new
/cgi-bin/koha/serials/subscription-add.pl?op=modify&subscriptionid=XXx
/cgi-bin/koha/serials/subscription-add.pl?op=dup&subscriptionid=XXX
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan:
Run these commands, grep should not return any occurences, prove should
return green:
git grep GetSerialStatusFromSerialId
git grep GetDistributedTo
git grep SetDistributedTo
git grep SetDistributedto
git grep in_array
git grep is_barcode_in_use
kshell
prove t/db_dependent/Serials.t
Signed-off-by: Pierre-Luc Lapointe <pierreluc.lapointe@inLibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 20400 added a routing list tab to the patron account in the
OPAC using Koha::Object. After changing the staff view too,
we can now safely remove GetSubscriptionsFromBorrower as it
is no longer used.
To test:
- Make sure that GetSubscriptionsFromBorrower is no longer used.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Fix for:
Field 'missinglist' doesn't have a default value
t/db_dependent/Koha/Acquisition/Booksellers.t
from mysql doc:
BLOB, TEXT, GEOMETRY, and JSON columns cannot be assigned a default
value.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
[1] Replace corrosponding => corresponding
[2] Replace containts => contains
[3] Replace item_level-itypes => item-level_itypes
[4] Replace Managment => Management
[5] Replace should returns => should return
Test plan:
Note that this patch only deals with POD lines or test descriptions.
So there is nothing to test, just read the patch.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Patch amended by RM: The release notes should not be modified
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Change parameters to a hashref.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Looks good to me.
Two calls in migration_tools/22_to_30 still in old style.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
C4::Biblio::GetBiblio can be replaced with Koha Biblio->find
Test plan:
Import batch, view issue history, search for items, see the image of a
bibliographic record, modify and delete records in a batch
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
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>
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>
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>
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>
ref($sub) eq 'ARRAY' should always be true, what we want is to call
can_edit_subscription if there is at least 1 serial for this
subscription.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Currently we have subscriptions with 300+ serials received.
It takes a lot of time to show serials-collection.pl (~20s).
This is especially troublesome when receiving serials, since after receival we get redirected to that page.
We no longer can receive daily serials in the allotted timeframe.
This quick and dirty fix prevents checking the subscription editing for each serial, but instead checks it for the first serial only.
This reduced page load time by ~18s
TEST PLAN:
1. Receive ~300 serials (or just a bunch :) )
2. Observe the gradual slowing of the receival action.
AFTER THIS PATCH:
1. Receive ~300 serials more (or just a bunch)
2. Observe a significant performance improvement.
Signed-off-by: Paul POULAIN <paul.poulain@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Without this patch, there is an inconsistency in subscriptions:
* a new subscription has no history end date set (as expected)
* if you renew it, a date is set.
This patch removes the setting of the history end date during renewal
Test plan:
* create a subscription, go to subscription-detail.pl page, tab "Summary". No History end date is set
* renew the subscription => a date has been set
* apply the patch
* create another subscription
* renew it => no history end date has been set
* sign-off
Signed-off-by: beroud <isabelle.beroud@univ-lyon3.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
--TEST PLAN--
1) View a subscription with no history end date
2) Search for an item with a subcription in OPAC
3) Under subscription tab click more details
4) The end date will be the current date
5) Apply patch and refresh
6) The end date will not be shown
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
/cgi-bin/koha/serials/serials-edit.pl?serstatus=*/+,2,3,'2016-12-12','2016-12-12',6,'jjj7','jjj8'%20--%20-&subscriptionid=1+and+1%3d2+Union+all+select+111+/*
The SQL query is not constructed correctly, placeholders must be used.
Subscription id and status list can be provided by the user.
This vulnerability has been reported by MDSec.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
/cgi-bin/koha/serials/serials-edit.pl?serstatus=*/+,2,3,'2016-12-12','2016-12-12',6,'jjj7','jjj8'%20--%20-&subscriptionid=1+and+1%3d2+Union+all+select+111+/*
The SQL query is not constructed correctly, placeholders must be used.
Subscription id and status list can be provided by the user.
This vulnerability has been reported by MDSec.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
/cgi-bin/koha/serials/serials-edit.pl?serstatus=*/+,2,3,'2016-12-12','2016-12-12',6,'jjj7','jjj8'%20--%20-&subscriptionid=1+and+1%3d2+Union+all+select+111+/*
The SQL query is not constructed correctly, placeholders must be used.
Subscription id and status list can be provided by the user.
This vulnerability has been reported by MDSec.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
In the staff client, when creating an order from a subscription
the vendor name should be shown in a separate column.
This patch adds that feature. The 'Vendor' column is added before
the 'Library' column since they appear in that order in Advanced
search.
Test plan:
0) [PREREQUISITES] In the Staff client, under Acquisitions, create
a Vendor and associated Basket if you don't already have them.
Then, under Serials, add a new Subscription using the Vendor
you've just created.
1) Go to Acquisitions, and under 'Manage orders' search for a vendor,
then click on 'Add to basket' and select 'From a subscription'.
2) Click 'Search' on the left hand side to search for all subscriptions.
Notice how there is no 'Vendor' column in the results table.
3) Apply the patch.
4) Repeat step 2. Confirm that the patch works, i.e. there is now
a 'Vendor' column which displays the vendor name.
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
GetItemnumberFromSerialId has no unit tests. It would be better to start
using our object system here.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
- Various fixes.
Test plan:
Once the makePreviousSerialAvailable syspref is enabled, receive a serial, and then another, then check that:
- the first received itemtype has been set to the "previous item type" value (set in the subscription).
- the first received has been made available.
- the last received serial itemtype has been set to the "item type" value (set in the subscription).
- 995$l is automatically prefilled.
Configure the serialsFieldsToAV syspref. When creating or editing a subscription, check that:
- the domain and/or origin and/or support fields are correctly displaying the authorized values configured in the syspref.
Signed-off-by: Chris <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When enabling the makePreviousSerialAvailable syspref, the previously
received serial's itemtype is set as defined in the subscription.
(Please note that the item-level_itypes syspref must be set to specific item.)
It is also made available.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
http://bugs.koha-community.org/show_bug.cgi?id=7767
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
On the same way as late issues, the serial status should be updated to
'claimed' when the issues as exported as csv.
QA note: The updateClaim and UpdateClaimdateIssues subroutine did almost the
same thing, I kick the second on off to centralize the code.
Test plan:
1/ Export some late issues as CSV (serials/claims.pl).
2/ Refresh the page (the export does not do it) and confirm that the
status, the claim date and the claim count have been updated.
3/ Select some others issues, select a notice and send the notification.
Confirm that the behavior is the same.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
An improper method call was left over in C4::Serials::NewIssue from the
switch from DBIx::Class to Koha::Object.
Test Plan:
1) prove t/db_dependent/Serials.t
2) Note the errors
3) Apply this patch
4) prove t/db_dependent/Serials.t
5) No errors!
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Added a new sub to Serials.pm to be able to get serials with their statuses.
Now the sub ModSerialStatus checks for other serials with an "expected" status before doing anything.
Also modified Serials.t to be able to test those changes.
Test Plan
1) Apply patch
2) Run ./t/db_dependent/Serials.t
3) Validate that there are no errors
4) Go on "Serial collection information" page for a serial of your choice
5) Click on "Generate next"
6) Change the status of the original serial from "late" to "expected"
7) Change the newly generated serial from "expected" to "delete"
8) Validate that there are no new serials created by instruction 7 and that the serial was deleted
9) Run ./t/db_dependent/Serials.t
With QA Fixes
- Use the constant instead of the code (1 vs EXPECTED)
- Avoid interpolation in query
- use selectall_arrayref instead of fetchall_arrayref
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1) Go to Serials -> Manage numbering patterns
2) Create .New Numbering Pattern.
3) Type in a name of 'Day, Month, Season' and a numbering formula of '{X} {Y} {Z}'.
4) Set up the X field as following: add 1, every 1, set back to 1, when more than 30.
5) Select the formatting for X. There should be six options available instead of the original three. Use the formatting 'Name of Day (abbreviated)'.
5) Set up the Y field to add 1 every 30 reset back to 1 when more than 12. Use the formatting option 'Name of month (abbreviated)'.
6) Set up the Z field to add 1 every 90 reset back to 1 when more than 4. Use the formatting option 'Name of season (abbreviated)'.
8) Select a frequency of 1/day.
9) Select a first issue publication date of Jan 1, 2016.
10) Set X to begin with 5 and have an inner counter of 5. Set Z to begin with 3 and have an inner counter of 10.
11) Click the 'Test Pattern' button.
12) Abbreviated versions of the day, month and season should appear in the test pattern.
Signed-off-by: sonia bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Mainly a
perl -p -i -e 's/^.*3.07.00.049.*\n//' **/*.pm
Then some adjustements
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
perl -p -i -e 's/^(use vars .*)\$VERSION\s?(.*)/$1$2/' **/*.pm
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
This code was written before the introduction of Koha::Object(s)
Considering the triviality of updating the code, we should go ahead
and switch this code to use Koha::Object(s) now.
Currently, all serials enumeration data is stored in conglomerated
fashion in serial.serialseq. This makes it extremely difficult to do any
reporting based on the individual sequence values due to this fact. In
addition to the formatted version of the sequence, we should be storing
the individual values as well.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Create a new subscription, and add serials to it. The new x y and
z fields should be populated with the same data the replaces {X} {Y} and
{Z} in the enumeration field.
4) Inspect some existing serials. The update script will have made a
best effort to recover the existing enumeration data to store in
separate fields.
Signed-off-by: Paul Landers <paul.landers@ttuhsc.edu>
(See comment #23)
This patch removes stray C4::Dates (date_fromat...) from
C4/Items.pm
C4/Log.pm
C4/Serials.pm
serials/acqui-search-result.pl
t/DateUtils.t
t/db_dependent/Items/GetItemsForInventory.t
tools/koha-news.pl
Some of them were inside comments etc.
To test:
- git grep 'C4::Dates' should give no result
- git grep 'format_d' should give no result
Exception: in one cron job there exists an own sub format_date, and occurences not
related to C4::Dates
- Search for regressions
http://bugs.koha-community.org/show_bug.cgi?id=14870
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
serials/acqui-search-results.pl looks like it should be revisited,
containing code that might not be needed. Searching a vendor
in serials still works witout a problem.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
This subroutine has been introduced in 2006, when C4::Serials has been
added to the codebase.
If you checkout this commit
commit 18d2cd0990
Date: Fri Jul 7 08:45:47 2006 +0000
this file replace C4/Bull.pm
You won't find any occurrences of this subroutine neither.
Interesting module's name by the way.
Test plan:
git grep ItemizeSerials
should not return any result
Followed test plan, no results found.
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>
Add a new field serial.publisheddatetext for displaying published date
in another format that dateformat syspref permit.
Signed-off-by: Cedric Vita <cedric.vita@dracenie.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Only superlibrarian users and users with superserials permission
can override this limitation.
This patch adds a new subroutine C4::Serials::can_claim_subscription.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
The upgrading of the DB was as required:
for each [PT/S] patron with the permission "claim_serials" ON,
the permission "superserials" became[/was kept to] ON.
Then, after having checked the DB upgrading, to test the currently
adding limitation:
> Users can only claim for serials related to their branch
, I reset 2 PT/S patrons-users to:
permission claim_serials: YES
permission superserials: NO
and I set the syspref "IndependendeBranches" to "Prevent".
For:
> Only superlibrarian users can override this limitation.
the S patron-user could list AND claim:
A) subscriptions of his own branch,
B) subscriptions of other branch,
C) subscriptions without branch.
For:
> Only users with superserials permission can override this limitation.
the PT patron-user could list:
A) subscriptions of his own branch,
B) subscriptions of other branch,
C) subscriptions without branch,
and could claim only:
A) subscriptions of his own branch,
C) subscriptions without branch.
NB: a subscription is selected to be claimed.
Then I set the syspref "IndependendeBranches" to "Don't prevent".
The behaviour was [exactly the same as in master] without the added
limitation.
On [S/PT] patrons, if permission claim_serials was NO, no Claims
link was available on Serials' page, either under "Prevent" or under
"Don't prevent".
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Added the results of Paola's testing to the commit message
as test plan.
Note to RM: Maybe we could add a note to the release notes, that
Koha now enforces superserials with independent branches better,
so people might have to adapt permissions in order to claim
for other branches.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Baptiste Wojtkowski
morgane alonso
Jonathan Druart
Josef Moravec
Katrin Fischer
Marcel de Rooy
Mark Tompsett
Julian Maurice
Olli-Antti Kivilahti
Paul Poulain
Luke Honiss
Kyle Hall
Andreas Roussos
Matthias Meusburger
remi
Karl Holten
Marc Véron
Jonathan Druart