Signed-off-by: Joy Nelson <joy@bywatersolutions.com>
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: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
(cherry picked from commit f863e478b9)
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
This patch adds a timestamp column to the borrowers table in kohastructure
and updatedatabase. (And also to the deletedborrowers table.)
A timestamp may be useful in synchronizing with external systems (among other
reasons).
Test plan:
Run updatestructure on an existing database, or install a new one.
Verify that the borrowers table has a timestamp now.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested updatestructure and running kohastructure.sql.
Passed t/db_dependent/Members.t.
updatedatabase.pl did not apply. I edited and then run it. Columns were added as expected.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Joy Nelson <joy@bywatersolutions.com>
Bug 10459: Follow up to update to atomic update methodology
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
New column created, no errors.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Joy Nelson <joy@bywatersolutions.com>
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: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
(cherry picked from commit 255596ae6c)
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Before Bug 16200 expired holds have used accounttype F which is also used by
other type of fines. This patch updates all existing expired holds to new
accounttype HE (Hold Expired).
To test:
-1. Make sure you translated the string in previous patch of this buug
1. Find a Patron with "Hold waiting too long" fines and go to his Fines tab
2. Change Koha's language to some other than English
3. Observe that "Hold waiting too long" is still in English
4. Apply patch and run database update
5. Go back to Patron's Fines tab
6. Observe that "Hold waiting too long" is now translated
Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
(cherry picked from commit 09de19c427)
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
When doing a hacked install off the master branch:
use ... {koha database name}
truncate creator_layouts;
truncate creator_templates;
truncate printers_profiles;
source installer/data/mysql/... {name of a sample_labels type file}
Warnings are generated, which may not be visible in the UI.
Most of the warnings were triggered by:
-/*!40000 ALTER TABLE `creator_layouts` DISABLE KEYS */;
-/*!40000 ALTER TABLE `creator_layouts` ENABLE KEYS */;
http://dev.mysql.com/doc/refman/5.7/en/error-messages-server.html#error_er_illegal_ha
In the Russian, the layout_name was truncated, because the layout_name was only 20. An atomic update sql and kohastructure.sql update were provided to widen it to 25.
http://dev.mysql.com/doc/refman/5.7/en/error-messages-server.html#error_warn_data_truncated
Also fr-FR, ru-RU, and uk-UA were slightly different in structure, so the structure was made the same as the other files.
See comment #1 for the test plan.
NOTE: pl-PL is likely very out of date, but is not affected in this regard.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Works, no more warnings
mysql> show warnings;
Empty set (0.01 sec)
No errors
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: 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: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This column has never been used and can be removed.
Test plan:
1/ update the schema
2/ prove t/db_dependent/Acquisition.t
should return green
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Test green pre & post patch
No errors
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
While many of us would like to get rid of biblioitems one day, the current
scheme includes a biblioitemnumber and a biblionumber in Items.
(Which is not so great..)
But also note that biblionumber is NOT defined as a foreign key in Items,
although a belongs_to relation has been added to the DBIx scheme!
This inconsistency should be resolved. The "remove biblioitem table"
operation is a large one, but in the meantime we better make biblionumber
a regular FK not a 'pseudo' one.
Note: If in an (very) exceptional case biblionumbers are found in items,
that do not exist in biblio, this patch prints a warning at upgrade
time and does not add the constraint.
@RM: Please update the DBIx scheme accordingly.
Test plan:
[1] Run the upgrade. Check if the FK constraint has been added.
[2] Remove the FK constraint. Change the biblionumber of one item to an
unexisting record. Run the upgrade again. Notice the warning.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested both cases: constraint added as well as warning printed.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If the new pref is named EnhancedMessagingPreferencesOPAC, it will show
up adjacent to EnhancedMessagingPreferences
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
- Change the preference Enhancedmessagingpreference description.
- Enable default EnhancedMessagingPreferences and OPACEnhancedMessagingPreferences.
- not sent e-mail it's necessary, when user call opac-messaging.pl directly..
Testing:
I Apply the patch
II Run updatedatabase.pl
0) Search OPACEnhancedMessagingPreferences preference;
1) Validate "OPACEnhancedMessagingPreferences show patron messaging
setting on the OPAC (NOTE: EnhancedMessagingPreferences must be
enabled).";
2) Disable OPACEnhancedMessagingPreferences preference;
3) Enable EnhancedMessagingPreferences preference;
4) On the OPAC -> user's settings, validate "your messaging" is not
showed.
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Works as expected. With the new syspref, patrons can be forbidden to
modify themselves their own messaging preferences.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Also, I like sysprefs
http://www.quickmeme.com/img/d9/d99723bc544e8d33572dc92f242a6f6e2dbe0126a2e35fe3de073d30d62002e6.jpg
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This feature is enabled by default, but the users are not aware of it
and it costs a lot of time processing to get the images.
There are 2 prefs to drive this feature: StaffAuthorisedValueImages and
AuthorisedValueImages. AuthorisedValueImages is not added by sysprefs.sql and
does not appear in updatedatabase.pl, we could easily imagine that
nobody uses it.
With XSLT enabled, the feature is only visible on a record detail page
at the OPAC, if AuthorisedValueImages is set.
Otherwise you need to turn the XSLT off. In this case you will see the
images on the result list (OPAC+Staff interfaces) and OPAC detail page,
but not the Staff detail page.
The idea of this patch is to introduce a quick switch if the feature is
not used by the library.
Test plan:
1/ Turn the pref on and set authorised_values.imageurl to NULL
Execute the DB entry
=> The pref have been turned off
2/ Turn the pref on and set an image for an authorised value
Execute the DB entry
You will get a warning
3/ Turn the pref off and set an image for an authorised value
Execute the DB entry
You will get a warning
4/ Turn the pref off and set authorised_values.imageurl to NULL
Execute the DB entry
You won't get a warning
Note that the opac detail page now checks the pref before retrieving the
images.
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Fixed update message 'that means'.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
* Add `AFTER` to DB update
* Change "Is standing order basket:" to "Orders are standing:"
* Disable item creation when adding from a staged file
* Correctly show is_standing for existing baskets
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This allows creation of special baskets that include standing orders.
These orders do not have a known quantity (and may not have a known
price in advance). Upon receipt, the received items are split into a new
completed order.
Test plan:
1) Run updatedatabase.pl.
2) Run prove t/db_dependent/Acquisition/StandingOrders.t . (and the
other Acquisition tests).
3) Create a new basket, mark it as a standing order basket.
4) Add an order to this basket, and notice that the quantity field is
missing (and thus not required).
5) Receive items for this order, and notice that the original order is
unchanged. The new child order line should have the correct price
and quantity information.
(Note: the QA tools output what seems to be a spurious spelling error
for Test::More's "isnt" in StandingOrders.t.)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This enhancment allows a library to prevent patrons from checking out
items if his or her guarantees own too much.
Test Plan:
1) Apply this patch
2) Find or create a patron with a guarantor
3) Add a fine to the patron's account
4) Set the new system preference NoIssuesChargeGuarantees to be less
than the amount owed by the patron
4) Attempt to check out an item to the guarantor, you will either
be warned or prevented from checking out based on your system
settings.
Signed-off-by: Cathi Wiggin <CWIGGINS@arcadiaca.gov>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Some libraries would like the ability to select the itemtype to request
when placing holds. For example, if a record has 3 copies of BookA and 3
copies of BookA in large print, this feature would allow a person to
place a hold on the record, but still be able to target only the Large
Print edition so that the first Large Print copy that becomes available
is targeted, rather than forcing the patron to select a particular copy
to hold.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Create a record with items of two or more itemtypes
4) Place a record level hold on the record while choosing one particular
itemtype
5) Check in an item from the record that is not of that itemtype
6) Notee it is not trapped for the hold
7) Check in an item from the record that does match the selected itemtype
8) Note the item is trapped for the hold
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Some libraries would like to be able to limit hold filling to items that
match the pickup library for a hold based on the item's home or holding
library. The patron's home library should not affect whether a patron
can place the hold, instead the hold will only be fillable when an item
matching the pickup location becomes available.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Note the new "Hold pickup library match" rules for "checkout, hold,
and return policy" and for "holds policy by item type"
4) Set the policy to "item's holding library"
5) Place a hold where the item's holding branch does not match
the pickup branch
6) Check in the item
7) Note it is not trapped for the hold
8) Update the item's holding branch to match the pickup branch
8) Check in the item
9) Note the item is trapped for the hold
10) Repeat steps 4-9 but for home branch instead
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as described
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 12752 has fixed a bug for installations upgrading from 3.14, but has
not fixed the problem for new installations.
Because of some wrong data manipulations, the names for a given letter
code may diverge.
In particular OVERDUE and PREDUE names of phone notices have been
wrongly modify by bug 11867: they have been set to the name of the first HOLD
notice.
Trying to be back on our feet, this update DB entry will try to guess
and set back up the correct name.
To know if your install is affected by this bug, the following SQL query
can help you:
SELECT code, name, message_transport_type
FROM letter
WHERE code="PREDUE" OR code="OVERDUE";
If the names are different for the same code, something went wrong.
Executing this update DB entry should fix the divergence.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Fix the problem, see comment #6 for test.
No koha-qa errors
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
[1] Upload_general_files
This will allow you to access the tools/upload form via the Tools menu.
And it will also allow you to add permanent uploads.
[2] Upload_manage
It will allow you to delete uploads from other users.
Note that anyone may delete his own uploads.
It is not meant to include upload_general_files.
In order to not disturb existing users that now have edit_catalogue and are
using the plugin (read: added at least one record to uploaded_files), we
will add the first permission for them. New users will need to be authorized
in the usual way thereafter.
Note: If you only have one of the other permissions checked in allows_add_by,
e.g. stage_marc_import, you can add temporary uploads, but not permanent
uploads.
Test plan:
We are only testing the dbrev here, not if the perm works as advertised.
[1] Run the dbrev and check that you see the perms with a description on
the Patron/Set permissions page.
[2] If you had records in uploaded_files and a user with edit_catalogue
*only*, verify that this user now also has upload_general_files.
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>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
To make things consistent, the attributes of the mappings (sort,
suggestible, facet) should be moved to the join tables
(search_marc_to_field).
Indeed the search_marc_map could represent a mapping for several search
fields with different attributes. Before this change it was not
possible.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Some installer files still refer to password_allowed.
The print statement of the db revision has been slightly adjusted.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
When creating a patron attribute type, there is a "Allow password"
checkbox. If checked, the librarian will be able to enter a password for
this patron attribute when editing a patron.
The goal was to allow a patron to log in with a secondary password.
However, this feature has never been implemented.
"""
commit 6fc62bcd32
CommitDate: Mon May 12 09:03:00 2008 -0500
extended patron attributes tables & syspref (DB rev 081)
- password_allowed (if set, staff patron editor will
allow a password to be associated with a value; this
is mostly a hook for functionality to be implemented
in the future.
"""
To decrease maintainability, this patch suggest to remove the 2 DB fields
borrower_attributes.password and
borrower_attribute_types.password_allowed
If they have not used by the library.
Test plan:
- Edit a patron attribute type and select "allow password"
- Edit a patron and defined a password for this attribute
- Execute the DB entry
- Note that you get a warning
- Empty the password field
- Execute the DB entry
- You do not get the warning and the 2 DB fields have been removed
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Frédéric Demians
Mark Tompsett
Marcel de Rooy
Brendan Gallagher
Lari Taskula
Kyle M Hall
Tomas Cohen Arazi
Colin Campbell
Jonathan Druart
Bouzid Fergani
Jesse Weaver
Brendan Gallagher
Chris
