As requested by QA, the sub should be moved.
Test plan:
See previous patches.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
This patch makes sure that the added granular permissions work as
advertised.
Note: The field owner was not included in the Koha::Upload->get response.
The code to verify if a user is allowed to delete an upload, is concentrated
in the template now. When get returns a Koha::Object, this check could be
relocated.
Test plan:
[1] Verify that the current user has permission for tools, or has
at least upload_general_files.
[2] Do you see Upload in the Tools menu? Follow the link.
[3] Upload a permanent file (with a category).
[4] Do you see the Delete button in the results form?
[5] Make sure that another user has no permission to upload.
[6] Login as that user and check the Tools menu.
Try the URL [yourserver]/cgi-bin/koha/tools/upload.pl
You should have no access to the upload form.
[7] Enable upload_general_files for this user. Go to upload and search for
the upload from step 3. You should not see a Delete button.
[8] Enable upload_manage for this user. Search for the upload again.
Delete the upload.
[9] Go to upload via the Cataloguing editor (856$u plugin) or add
parameter "plugin=1" to the URL. You should not see the Tools menu.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
The three permissions in tools/upload-file.pl are moved to a custom
routine in DBIx's UploadedFile.pm. An additional granular permission
upload_general_files is added. (The dbrev patch will contain it too.)
At some point in time this could be moved to a Koha::Object class.
The routine is tested in Upload.t.
Test plan:
[1] Run t/db_dependent/Upload.t
[2] If you only apply this patch, you can also test uploading with a
user that has edit_catalogue but does not have tools or circulate.
Upload status should say: Denied.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
This patch replaces the occurrences of
my @foo = $cgi->param('foo');
with
my @foo = $cgi->multi_param('foo');
perl -p -i -e
's/^(\s*my\s*@\w+\s*=\s*)\$(cgi|input|query)\->param\(/$1\$$2\->multi_param\(/xms'
**/*.pl
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Rename not_borrowered_since to not_borrowed_since
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
This patch adds the ability to select a patron list for deletetion
when using the Batch patron deletion/anonymization tool. It also adds
buttons to the the patron lists table to access both the batch deletion
and batch modification directly from the lists view.
This is a squash of previous patches but now adds a patron_list_id
parameter to C4::Members::GetBorrowersToExpunge and uses that routine to
fetch patrons from a list.
Test Plan:
1) Apply this patch
2) Create a list of patrons with the new Patron Lists feature
3) Try using the batch edit link form the lists table
4) Try using the batch delete link from the lists table
5) Verify previous functionality has not changed
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Patron batches are correctly passed to the edit and delete pages.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Import borrowers tool explodes if userid already exists. This error
should be caught to avoid the script to explodes.
TEST PLAN
---------
1) back up DB
2) drop DB, create empty DB
3) Apply patch 15842
4) web install all the sample data
5) login as system user and import patron data
-- sample provided to trigger error.
-- you will get a DBIx::class exception
"Duplicate entry ' for key 'userid'"
6) Apply this patch
7) Repeat steps 2-5
-- patrons won't be inserted but an error
will be nicely displayed in the error list.
8) run koha qa test tools
Note that it would be easy to insert the patrons anyway and generate a
userid based on the surname and firstname.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
The patron attributes displayed on editing a patron are not displayed if
limited to another library.
C4::Members::Attributes::SetBorrowerAttributes will now only delete attributes
the librarian is editing.
SetBorrowerAttributes takes a new $no_branch_limit parameter. If set,
the branch limitations have not effect and all attributes are deleted
(same behavior as before this patch).
Test plan:
1/ Create 2 patron attributes, without branch limitations.
2/ Edit a patron and set a value for these attributes
3/ Limit a patron attributes to a library (one you are not logged in
with).
4/ Edit again the patron.
=> You should not see the limited attributes
5/ Edit the patron attributes and remove the branch limitation
=> Without this patch, it has been removed from the database and is not
displayed anymore.
=> With this patch, you should see it.
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
The commit b5ecefd485
Date: Mon Feb 3 18:46:00 2003 +0000
had a funny description:
Added function to check if a MARC subfield name is "koha-internal"
(instead of checking it for 'lib' and 'tag' everywhere); temporarily
added to Koha.pm
"Temporarily", since 2003, everything is relative, isn't it? :)
The thing is that GetMarcStructure returns hash like
field_200 => {
subfield_a => {
%attributes_of_subfield_a
},
%attributes_of_field_200
}
The attributes for field_200 can be 'repeatable', 'mandatory', 'tag', 'lib'.
We don't want to loop on these values when looping on subfields.
Since there are just { k => v } with v is a scalar (string), it's easier
to test if we are processing a subfield testing the reference.
At some places, we don't need to test that, we are looping on values
from MARC::Field->subfields which are always valid subfields.
Test plan:
1/ Edit items using the batch item mod tool
2/ display and edit items via the cataloguing module.
You should not see any changes between before and after the patch
applied.
Tech notes:
We need to check what we are processing when we loop on 'subfields' from
GetMarcStructure, not from MARC::Field->subfields.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
To retrieve a patron image, we can call Koha::Patron::Images->find or
Koha::Patrons->find->image
Both will return a Koha::Patron::Image object.
Test plan:
1/ From the patron/member module, open all tabs on the left (Checkouts,
detail, fines, etc.)
The image should be correctly displayed.
2/ At the OPAC, on the patron details page (opac-memberentry.pl) the
image should be displayed as well.
3/ Same on the sco module.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The C4::Members::RmPatronImage just removed a row in patronimage.
This can be accomplished using the delete method of Koha::Patron::Image.
Test plan:
From the patron defail page, try to delete the image of a patron.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The C4::Members::PutPatronImage inserted/updated the image of a patron.
This can be done easily with ->find->set->store or ->new->store
Test plan:
1/ Modify the image of a patron from the patron detail page
2/ Add an image to a new patron
3/ Use the "Upload patron images" tools (tools/picture-upload.pl) to add
or modify the image of a patron
4/ Use the "Upload patron images" tools (tools/picture-upload.pl) to add
or modify the image of several patrons, using a zip file.
Stress the script trying to get as many errors as possible (wrong
cardnumber, wrong mimetype, file does not exist, etc.)
With this patch, if the cardnumber does not exist, you will get a
specific error "Image not imported because this patron does not exist in
the database"
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
There are 3 subroutines in C4::Members to get, add and delete patron
images:
- GetPatronImage
- PutPatronImage
- RmPatronImage
By creating these 2 Koha::Patron::Image[s] classes, we could remove them easily.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The 'borrower' should not be used anymore, especially for new code.
This patch move files and rename variables newly pushed (i.e. in the Koha
namespace).
Test plan:
1/
git grep Koha::Borrower
should not return code in use.
2/
Prove the different modified test files
3/ Do some clicks in the member^Wpatron module to be sure there is not
an obvious error.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as described. Tested with Circulation, Members/Patrons, Discharge,
Restrictions modules and the must common functionalities
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
This patch adds:
- a new DB field items.new.
- a new page to configure this new status
(tools/toggle_new_status.pl).
- a new cronjob script (misc/cronjobs/automatic_item_modification_by_age.pl
was misc/cronjob/toggle_new_status.pl)
Why this status is useful for some libraries ?
The use cases are:
- to know easily what are the new items (with a simple sql query).
- to display an icon in the search results.
- issuing rules can be adapt for new items. Automatically (using the
cronjob script), the status change (depending the configuration) and
the item can be issued, for example.
- a RSS/Atom feeds can be created on these new items.
Test plan:
- log in with a librarian having the tools > items_batchmod permission.
- navigate to Home > Tools > Automatic item modifications by age (was: Toggle new status)
- click on the edit button
- there are 3 "blocks":
* duration: the duration during an item is considered as new.
* conditions: the status will change only if the conditions are meet.
* substitutions: if there is no substitution, no action will be done.
You can add some change to apply to the matching items.
E.g. ccode=3
new=''
If the value is an empty string (in other words, the input does not
contain anything), the field will be deleted.
You can create as many rules as you want.
- test the interface : add/remove rule, conditions, substitutions,
submit the form, edit, etc.
(There is a looot of JS everywhere, so certainly a looot of bugs...).
- when you have your rules defined, you can now launch the cronjob
script without any parameter.
A report will be displayed with the matching itemnumber and the
substitutions to apply. Verify results are consistent.
- launch the script with the -c argument and verify values have been
modified depending the substitution rules.
Signed-off-by: juliette et remy <juliette.levast@iepg.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 11023: Add the ability to specify fields from biblioitems table.
Test plan:
Same as before but try with fields from the biblioitems table.
Signed-off-by: juliette et remy <juliette.levast@iepg.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 11023: Add UT for C4::Items::ToggleNewStatus
Test plan:
prove t/db_dependent/Items/ToggleNewStatus.t
Signed-off-by: juliette et remy <juliette.levast@iepg.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 11023: FIX - condition on biblioitems table does not work
If a rule contains a condition on the biblioitems table, the match won't
work. This patch fixes this issue.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 11023: Use DBIx-Class to retrieve column names
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 11023: Don't use the biblioitems fields for the subtitution
It's dangerous to allow a change on the biblioitems fields with this
feature.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 11023: Rename the duration parameter with 'age'
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 11023: The age parameter should be a number
The template should check if the age parameter is correctly filled
(should be a number).
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 11023: Change the name of the feature
Originaly this feature only permits to update the "new" field.
Now all item fields can be updated.
The name of the feature is now "Automatic item modifications by age".
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 11023 [QA Followup]
* Update DB version
* Fix capitalization error
* Rename misc/cronjobs/toggle_new_status.pl to misc/cronjobs/automatic_item_modification_by_age.pl
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 11023 [QA Followup] - Complete the renaming of "toggle new status" to "automatic item modification by age"
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
When exporting records (tools/export.pl or misc/export_records.pl), a
file of ids (authid or biblionumber) can be passed to filter the
results.
Bug 14722 has broken this behavior.
Test plan:
Export records and specify a list of records to filter the results.
Prior to this patch, the record with the id 1 was exported.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
To verify:
- Download attachment 'Goethe with umlaut' from Bug 15684
- Go to Tools > Quote Editor
- Click "Import quotes" and select the file
- The quotes display in a table. Click 'Sav quotes'
- Result: Nothing happens
To test:
- Apply patch
- Repeat steps above
- Verify that you get a message '2 quotes saved' and that the quotes
are added in to the quotes table
- Test with attachment 'sample quotes' as well
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Batch patron modification should not offer to update patron attributes
with values which are designated as unique since such attributes are
required to be unique to a single patron.
Test plan:
Create some patron attributes, some should be unique.
Use the batch patron modification tool to modify patrons.
With this patch, the patron attributes marked as unique won't be
display anymore.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
The patron's information displayed in the member module
(includes/circ-menu.inc and includes/member-display-address-style-*.inc)
are not always displayed the same way.
Sometimes the streetnumber is missing, sometimes it's the streettype.
Sometimes the streettype is after the address, sometimes before...
Test plan:
Go on a patron detail page, and open all the tabs on the left (Check
out, Fines, Notices, etc.)
Without this patch, the patron's info displayed will differ from one page to
another.
With this patch, they will be displayed the same everywhere.
Followed test plan, works as expected. (Tested both patches together.)
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
To test:
- For a patron, permissions 'catalogue' and 'records_batchmod' only
- Log in as this patron
- Go to /cgi-bin/koha/tools/batch_record_modification.pl
Without patch: You have no permisson to acces the page.
With patch: Page 'Batch record modification' displays as expected.
(Amended to fix wrong test plan)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Bug 15332 fixed a bug but introduced a bigger one. Even if dateenrolled and
dateexpiry are not modified, they will be updated to today.
Indeed, dt_from_string returns today without parameters.
Test plan:
- Set dateenrolled and expirydate for a patron
- Using the batch patron mod tool, update any field but dateenrolled and
expirydate.
=> Without this patch, the 2 date fields should be set to today
=> With this patch applied, the 2 date fields should not have been
modified.
Signed-off-by: Karam Qubsi <karamqubsi@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
The repeatable patron attributes are not correctly managed and can cause
data lost. To avoid that, the easier way is not to display them in the
batch patron modification tool.
This should be implemented, as a new enhancement.
Test plan:
Create some patron attributes, some should be repeatable.
Use the batch patron modification tool to modify patrons.
With this patch, the patron attributes marked as repeatable won't be
display anymore.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Works as described, no koha-qa errors
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Test this patch with the previous one.
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
These 2 subroutines are now not necessary anymore, we can use
Koha::Authority::Types to retrieve the authority types.
This patch won't be easy to test. Indeed, a lot of file are updated.
To test it I would suggest to focus on the merge authority
You should also confirm that the authtypecode and the authtypetext
values are correctly displayed when navigating in the authority module.
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
The existing Koha::Authority does not use Koha::Objects and does not
exclusively deal with DB objects.
It makes much sense to move it to let the space free for a
Koha::Authority and Koha::Authorities modules based on Koha::Object.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This patch is a _requirement_ to Bug #12771, and will be necessary once we start managing more than 3 levels of overdue notice
TEST PLAN
1) Create or improve on overduerules data
.1) Intranet -> tools -> overdue notices
.2) Make sure to have data in first, second and third tabs
.3) Make sure to have checked mixes of Email/Phone/Print/SMS (depending on availability)
.4) Make sure to have different letters and delay on first/second/third tab for at least one category
.5) Remember it all.
2) Apply patch
3) run installer/data/mysql/atomicupdate/update_13624_overduerules_transport_type.pl
4) run t/db_dependant/Overdues.t
5) Validate Overdue Notice page
.1) validate data entered previously is still there
.2) Add some more, save changes, validate
In installer/data/mysql/atomicupdate/update_13624_overduerules_transport_type.pl
- A new column and primary key, 'overduerules_id', is added to the table 'overduerules'
- A new column referencing a foreign key, 'overduerules_id', is added to the table 'overduerules_transport_types'
- The columns 'branchcode' and 'categorytype' are removed from the table 'overduerules_transport_types'
- Data is migrated from the old tables to the new ones
In installer/data/mysql/kohastructure.sql :
- Table 'overduerules'
- Added a primary key named 'overduerules_id'
- Table 'overduerules_transport_types'
- Added a foreign key named 'overduerules_id'
- Dropped columns 'branchcode', 'categorycode' since we now have them referenced through 'overduerules_id'
In tools/overduerules.pl
- INSERT and DELETE queries on 'overduerules_transport_types' were changed to reflect the new schema
In C4/Overdues.pm :
- The SQL query of the function 'GetOverdueMessageTransportTypes' is changed to take into account the new design of 'overduerules_transport
In t/db_dependent/Overdues.t :
- The INSERT calls before the tests were changed to take into account the new design of 'overduerules' and 'overduerules_transport_types'
Sponsored by : Halland County Library
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Martin Persson <xarragon@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch makes the default circ rules and notices/slips to edit
the logged in branch, if one is set.
Test Plan:
1) Apply this patch
2) Log into staff side, and set your library
3) Browse to Tools/Overdue notice/status triggers
4) Note the actions displayed are for your library
5) Select "All libraries"
6) Note the actions displayed are for "All libraries"
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If formatted dates are sent to DBIx::Class on update/insert, the date
will be set as 0000-00-00 (except if the format is yyyy-mm-dd).
Test plan:
Use the batch patron modification tools to update the dateenrolled or
dateexpiry values for at least 1 patron.
Without this patch, the modified value will be updated to 0000-00-00,
with this patch, the correct value will be set.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Add bibliotiems to the 'available fields' list for
module 'Holds' (aka reserves).
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
This patch is to display corrextly the new dmydot date format e.g. after
using the datepicker or in messages for the user, in following files:
- koha-tmpl/intranet-tmpl/prog/en/includes/calendar.inc
- koha-tmpl/intranet-tmpl/prog/en/includes/date-format.inc
- koha-tmpl/intranet-tmpl/prog/en/includes/patron-search.inc
- koha-tmpl/intranet-tmpl/prog/en/modules/tools/holidays.tt
- koha-tmpl/opac-tmpl/bootstrap/en/includes/calendar.inc
- tools/holidays.pl
To test:
- Apply patch
- Make sure that you have syspref dateformat set to dmydot
- Use datepicker in OPAC (modify birth date), verify that after
choosing a date, it is displayed correctly in the datepicker
- Use datepicker at several places in OPAC, verify that after choosing
a date the date displays properly in datepicker and that the dater format
is properly indicated (e.g. near birth date or near "Specify due date").
- Verify that datepicker works well with hoiday editing and that "From date:"
displays properly
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(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>
This patch fixes the display of exceptions (was iso, is now syspref).
See comment #14 and attachment #15
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Followup for comment #10
To test:
- Go to Home > Tools > Calendar
- Add, edit, delete the different types of holidays and exceptions
- git grep 'C4::Calendar' and test such files
- git grep daysBetween to make sure that this sub is not used
- prove t/Calendar.t
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch removes C4::Dates from:
Remove C4::Dates from:
- tools/exceptionHolidays.pl
- tools/holidays.pl
- tools/newHolidays.pl
- C4/Calendar.pm
To test:
- Go to Home > Tools > Calendar
- Add, edit, delete the different types of holidays and exceptions
- git grep 'C4::Calendar' and test such files
- prove t/Calendar.t
(Amended following comments #3 and #4 / mv)
(Amended following comment #7 / 25.10.2015 / mv
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
http://bugs.koha-community.org/show_bug.cgi?id=14945
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The batch records modification tool close STDERR, it's useless and hide
warnings/errors.
Like the other processes using the BackgroundJob module, this one should
let it open.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The origin framework is not passed on modifying the records and so the
default one is used.
This can caused data lost.
Test plan:
- Create a bibliographic record and specify a framework (not the default
one).
- Use the Batch records modification tools to modify it.
=> Without this patch, the default framework (framework code "") is used
and can deteriorate the record
=> With this patch, the record is saved using the original framework
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Tested framework is lost using tool without patch
Problem gone with patch
No qa errors
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When using the batch deletion tool, if the script attempts to delete an
undeletable item, the script will die with the error:
Label not found for "next BIBLIONUMBER" at
/usr/share/koha/intranet/cgi-bin/tools/batch_delete_records.pl line 172.
Test Plan:
1) Attempt to batch delete a record with an item that cannot be deleted
2) Note error
3) Apply this patch
4) Repeat step 1
5) Note the error no longer occurs
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised. Follow comment 5 to reproduce the issue
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
I have not tested this patch, but looking at the code it is obviously a mistake.
If an error occured, we rollback and skip this record.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Be kind and return 0 if the sample file has been generated correctly.
Otherwise you are a bad guy and you make Plack returns an internal error
(exited nonzero: 1 at /home/vagrant/kohaclone/tools/import_borrowers.pl line 390.)
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Works as expected
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Works as expected here too.
This patch does the following:
[1] Adjust authorities_merge_ajax just as in bug 14588.
[2] Replace some indirect syntax for fetch GGI::Cookie.
[3] Along the way replace some new CGI's. Note that I am not aiming to
replace them Koha wide. The "fetch class" variant is less readable.
NOTE: The changes to tools/upload-file.pl and upload-file-progress.pl
are moved to report 14321.
Test plan:
[1] Run the URL authorities/merge_ajax.pl in staff.
[2] Upload a file with Stage MARC records for import.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
[1] It runs, but also before patch
[2] File uploads without problem
No errors
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We could certainly remove 1 or 2 call to CGI->new in tools/background-job-progress.pl
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If a patron has restrictions and a CSV file of patrons to be overwritten
is uploaded but has no debarred / debarredcomment columns, the a new
restriction will be added that combines all the existing restrictions (
i.e. a new debarment based on the existing borrowers.debarred
and borrowers.debarredcomment fields ).
Test Plan:
1) Create a patron with one or more restrictions
2) Import a CSV file that updates that patron, but with no debarred columns
3) Note a new restrictions is created
4) Delete the new restriction
5) Apply this patch
6) Re-import the CSV file again
7) Note that no new restriction is created
8) Add debarred and debarredcomment columns to the CSV file with a test
date and description
9) Re-import the CSV file again
10) Note the new restriction is added to the patron
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Daniel Grobani <dgrobani@samuelmerritt.edu>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Why a refactoring was need for this script?
The export tool (tools/export.pl) can be called from the command line
and some parts of code were unnecessarity complicated (just look at the
code, you will understand).
Worse still, the script does not provide the same options for both
interface. For instance you cannot export records given a range of
biblionumbers, authids, callnumbers, etc. from the commandline.
What does this patch?
1/ Important: The script tools/export.pl does not work anymore if called from
the command line (should be in the release notes).
2/ The code used to generated a file (csv, iso2709 or xml) has been moved to a new
module (Koha::Exporter::Record) and tests have been provided.
3/ No change is done on the web interface
4/ Some new options have been added to the commandline script
(misc/export.pl):
- starting_authid
- ending_authid
- authtype
- starting_biblionumber
- ending_biblionumber
- itemtype
- starting_callnumber
- ending_callnumber
- start_accession
- end_accession
5/ There is a change in the behavior if an error occurs:
Can't call method "as_usmarc" on an undefined value at Koha/Exporter/Record.pm line 114.
record (number 5530) is invalid and therefore not exported because its reopening generates warnings above at Koha/Exporter/Record.pm line 117.
Before this patch, they were not displayed (using the command line).
What does not do this patch?
It does not provide the 'clean', 'timestamp' and 'deleted_barcodes' options to
the web interface (same as before).
What about the perfs?
With a DB with ~800 biblios (MARC21)
Before: perl tools/export.pl 14.79s user 0.83s system 71% cpu 21.905 total
After: perl misc/export.pl 17.19s user 0.84s system 75% cpu 24.018 total
With a DB with ~6400 biblios (UNIMARC)
Before: perl tools/export.pl 26.55s user 0.76s system 76% cpu 35.498 total
After: perl misc/export.pl 26.78s user 0.84s system 80% cpu 34.494 total
How to test this patch?
Test plan:
A. Web interface:
1/ On the current master, export some records, biblios and authorities (with
the 3 differents exports) playing with the different filters (item type,
libraries, callnumber, accession date, don't export items, remove
non-local items, don't export fields, etc.).
2/ Apply this patch, export again the same records, and compare the
generated files. They must be identical!
3/ Confirm that the export features on the checkout list
(circ/circulation.pl) works as before this patch.
B. The command line
1/ On the current master, export some records, biblios and authorities (with
the 2 differents exports) playing with the different options (date,
deleted_barcodes, clean).
2/ Apply this patch, export again the same records, and compare the
generated files. They must be identical!
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a new column to koha_news that links a
borrowernumber to each item. This allows Koha to display the
author for each entry which makes it suitable as a simple CMS.
Changes (from rejected patch):
* Added missing kohastructure.sql changes.
* Turned the atomic update file into a SQL file and changed name
in accordance with wiki guidelines.
* Changed SQL syntax and naming to be consistent with existing code.
* Attached test plan to commit message.
Test plan:
* You need at least one news item, log in and add one from
'Administration' -> 'Tools' -> 'News'.
* Apply the patch.
* Apply database upgrade (directly or indirectly).
* Go back to Staff interface and post a new news item.
* Use the mysql command line client to connect to the Koha installation's database:
mysql -u kohaadmin -p -D koha (change username and database to values
appropiate for your system).
* Execute the following query: SELECT title, borrowernumber FROM opac_news;
* Inspect the results, the 'borrowernumber' column should be NULL for all news items
created before the patch was applied, and non-NULL for the new item created AFTER
the patch was applied.
Optional: Remove database changes via:
ALTER TABLE opac_news DROP FOREIGN KEY borrowernumber_fk;
ALTER TABLE opac_news DROP COLUMN borrowernumber;
Sponsored-By: Halland County Library
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
