This patch allows patrons to create thier own password during OPAC self
registration. It sets the password field to be hidden by default, and
allows for a system generated password if no password is supplied and
field is not mandatory
1 - Apply patch
2 - run updatedatabase.pl
3 - Check syspref "PatronSelfRegistrationBorrowerUnwantedField" - it
should contain 'password'
4 - Check self registration on opac - there should be no change
5 - Remove 'password' from PatronSelfRegistrationBorrowerUnwantedField
6 - Password field should now be visible in OPAC self registration
7 - Register a patron: If no passwor is supplied you should get a system
generated password
8 - Register a patron with a password, your password should be used
9 - Add 'password' to PatronSelfRegistrationBorrowerMnadatoryField
10 - Attempt to register a patron with no password - it should fail
11 - Try all combinations if mismatched/short/missing passwords and view
correct error messages
12 - prove t/db_dependent/Members.t
Sponsored by : Do Space (www.dospace.org)
Signed-off-by: Jesse Weaver <jweaver@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
This table is not used anymore and can be removed.
Test plan:
In your sql cli:
SHOW TABLES;
should return nozebra if your DB has been created before bug 7440.
Apply this patch and execute the update DB entry.
Now the table should have been dropped.
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
The 2 columns password and userid are not sync and could cause errors
when deleting patrons.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
If set to Yes, OPAC search results and details will include buton from
Open Library Raed API.
In addition, Number of titles held in Open Library and the results link
will be reported on the search results screen.
Signed-off-by: Nicole Engard <nengard@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
On deleting a patron, all the tags approved by this user will be
deleted.
This can cause data lost.
Test plan:
0/ Do not execute the update DB entry
1/ Create 2 patrons A, B
2/ Create some tags with patron A logged in
3/ Approve them with patron B logged in
4/ Delete the 2 patrons
=> The tags have been deleted
5/ Execute the DB entry
6/ Repeat 1,2,3,4
=> The tags have not been deleted and are still shown on the interface
(result, detail, tags module)
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Bug 14821 removed the items which were not checked out, but some
libraries considered it as a bug.
So let's add a new pref to control this behavior.
Test plan:
0/ Execute the updatedb entry and set ShowAllCheckins to "Do not show"
(default)
1/ Check an item in.
If the item was not checked out, it won't be listed
2/ Turn the pref to "Show"
3/ Check an item in
If the item was not checked out, it should be listed
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Nearly all cellular providers allow a person to send an text message to a cellular
phone by sending an email to phonenumber@provider. We can leverage this capability
to add the ability for Koha to send sms messages to patrons without the need to
subscribe to an sms gateway server.
Basic plan:
1. Add a table sms_providers to the db to tell Koha what service providers are available, and what domain emails should be sent to.
2. Add borrowers.sms_provider_id to tell Koha which mobile service the patron subscribes to for the number given in smsalertnumber
3. Modify Koha to send an email rather than using SMS::Send if the driver is set to 'Email'
Test plan:
0) Get a mobile phone
1) Apply the patch
2) Run updatedatabase.pl
3) Set the value of SMSSendDriver to 'Email'
4) Go to the admin page, the "Additional parameters" area should now have the link "SMS cellular providers"
5) On this page, add some providers. Make sure to add the provider for your own cellular phone service.
Here are some examples:
Sprint phonenumber@messaging.sprintpcs.com
Verizon phonenumber@vtext.com
T-Mobile phonenumber@tmomail.net
AT&T phonenumber@txt.att.net
Only add the domain part in the 'domain' field. So for Verizon, that would be 'vtext.com'
6) Create an account for yourself, add your SMS number, and select your provider from the dropdown box directly below it.
7) Enable SMS messaging for Item check-in and Item checkout
8) Check out an item to yourself
9) Run process_message_queue.pl
10) Wait! You should receive a text message shortly, when I tested it, I received my sms message within the minute.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1) Apply patch
2) Run updatedatabase.pl
3) Go to advanced search in Staff Client (ie /cgi-bin/koha/catalogue/search.pl)
4) Confirm that it says 'Non-fiction' in the 'Any content' drop-down menu under 'Subtype limits'
5) Go to item search (ie /cgi-bin/koha/catalogue/itemsearch.pl)
6) Confirm that it says 'Non-fiction' under 'Collection code'
7) Go to advanced search in OPAC (ie /cgi-bin/koha/opac-search.pl) and click 'More options'
8) Confirm that it says 'Non-fiction' in the 'Content' drop-down menu
9) Go to the details page for a non-fiction book in the OPAC (ie /cgi-bin/koha/opac-detail.pl?biblionumber=2) and click 'Holdings' tab
10) Confirm that it says 'Non-fiction' under 'Collection' heading
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Marc Véron <veron@veron.ch>
Amended to fix typo in sql statement.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
To make life easier when multiple instances are uploading temporary
files to Koha, this patch adds the database name to the upload subfolder
in your /tmp folder.
Note: Although multiple instances could share the same subfolder for
temporary storage (hashvalue is based on a timestamp too), it will be
better to separate them for efficient housekeeping (removing older or
partial files with a cronjob etc.)
Since multiple instances come with separate permissions, keeping them in
separate folders will be much simpler.
Permanent storage is not affected by this patch. The location of permanent
storage is ruled by the upload_path in each config file. Sharing that
space is not recommended too.
Although it may not be strictly necessary yet to remove files from the old
temp storage folder (before the 3.22 release), the accompanying db rev
performs that housekeeping task.
Test plan:
[1] Do not yet apply this patch. Upload a temporary file (use the
tools/upload.pl script without selecting a category).
[2] Check /tmp/koha_upload.
[3] Apply this patch. Run the db rev with web installer.
[4] Upload another temporary file.
[5] Check /tmp for folder [your_database]_upload.
[6] Check that /tmp/koha_upload is gone and the associated records too.
[7] Run the adjusted t/db../Upload.t
Followed test plan. Could not do steps before applying patch [1]-[2]
(I suppose a local permission problem).
After applying patch and updating db file appears in /tmp/[database]
as expected.
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
This patch includes:
[1] Adds primary key borrowernumber to new table.
[2] Fixes collation.
[3] Removes manual PK in DBIx schema file.
[4] Fixes typo CompletePasswordRevovery.
[5] Removes use strict from opac-password-recovery; Modern::Perl is used.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
I've addressed a lot of Liz Rea's points.
1. I have moved the code from updatedatabase.pl and kohastructure.sql to a file in the atomicupdates directory.
1a. The feature is now off by default when the atomicupdate is run.
2. The password reset link is now visible on the home page, in the modal box and on opac-user.pl .
3. The password recovery pages now use bootstrap markup.
4. I am unsure here. I see "New Password:" and "Confirm new password:".
5. This should still work :).
6. I could not reproduce.
7. I have added the userid field.
You can now reset the password by submitting either your useid or email address.
Both fields can be filled, but the email address must be one of the borrower's (email, emailpro or b_email).
When entering only the email address and two borrowers use that same address, the system tells the user to try with another address or to specify his userid.
8. The text is in the atomicupdate file. Have at it, anyone.
Concerning the email. It is inconvenient for the use to have to wait X minutes for the message queue the be processed.
Maybe we could add a sub in Letters.pm that:
Takes the same argments as EnqueueLetter
Sends the letter.
Saves the letter in the message queue with a 'sent' status.
TEST PLAN:
Setup)
1) apply the patch
2) go to system preferences OPAC>>Privacy and set 'OpacResetPassword' to ON.
2b) make sure that OpacPasswordChange is also ON.
A)
1) refresh front page, click on 'Forgot your password' and enter a VALID address
1b) Also try an INVALID address (valid yet not in your koha db). An error message will show up.
2) An email should be received at that address with a link.
3) Follow the link in the mail to fill the new password.
Until a satisfactory new password is entered, the old password is not reset.
4) Go to main page try the new password.
B)
1) Repeat the password reset, this time use the userid (username) field.
2) Try to reset the password using a userid and an email not linked to the account. An error appears.
3) Make sure the borrower has many available email addresses.
4) For each email, reset the password using both the userid and the email. The link should be sent to the specified address
C)
1) Make sure two borrowers use the same email.
2) Repeat the reset procedure in test case A). An error message appears
http://bugs.koha-community.org/show_bug.cgi?id=13068
Author: Maxime Beaulieu <maxime.beaulieu@inlibro.com>
Followed test plan. Works as described.
Signed-off-by: Marc Veron <veron@veron.ch>
New sign-off after testing all patches together
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
It's a bit confusing to have RESERVESLIP named "Hold Slip", we should
finish the job and recode the slip.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Try printing a hold slip, you should note no difference
from pre-patch behavior
Followed test plan. The slip is triggered if you want to check out
an item that is reserved / on hold for another patron. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is already a syspref called "OverdueNoticeBcc" for sending Bcc
copies of mails sent for overdues and other notices. This patch add a
new syspref ClaimsBccCopy to bcc the claimacquisition and clamissues
alerts.
Changed the wording of the system preference to:
[Send|Don't send] blind copy (BCC) to logged in user when sending
serial or acquisitions claims notices.
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Currently if the AnonymousPatron system preference is in use, all patron
data is anonymized. Some libraries would like to be able to see the last
patron who returned out an item ( in case of damage ) but still keep all
other patrons anonymized.
* Add the table items_last_borrower ( id, itemnumber, borrowernumber )
* Add new system preference StoreLastBorrower
* If StoreLastBorrower is enabled, upon checkin have Koha insert into
this table the patron who last returned this item. Replace existing
row based on itemnumber if exists.
* If table has a row for a given item, link to the patron from the item
details page.
Test plan:
1) Apply patch
2) Run updatedatabase.pl
3) Enable StoreLastBorrower
4) Issue an item to a patron and return said item
5) Issue the same item to a second patron, do not return it.
6) View moredetail.pl for the given bib, find the given item. There
should be a new field in the history list 'Last returned by' with a link
to the last patron to return the item.
Optionally, you can also verify this works even if patron issuing
history has been set to anonymize issues upon return.
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Jen DeMuth <JDeMuth@roseville.ca.us>
Signed-off-by: Tom Misilo <misilot@fit.edu>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
If a record has more than 20 items, all the items over 20 will show as
available on the search results even if they are not!
This is a hard coded limit in the Search module. This number should be
configurable.
Test Plan:
1) Create a record with more than 20 items
2) Set all the items to waiting holds or in transit
3) Search for results that will include that item
4) Note some say they are available even though they are not
5) Apply this patch
6) Run updatedatabase.pl
7) Set the new system preference MaxSearchResultsItemsPerRecordStatusCheck
to a number larger than the number of items on your record
8) Re-run the search
9) Note that the hold and transit statuses for the items are now correct
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Currently the fee is applied on if all items for the record are issued
and at least one hold already exists on the record.
This patch does not give a complete answer to the problem (see
discussion on bug 13592 for the other user's expectations).
It only adds the ability to charge for any hold placed regardless of the
conditions.
Test plan:
1) Execute the updatedb entry to insert the new pref
2) Confirm that the behavior is the same as before applying this patch
3) Change the HoldFeeMode pref to 'always'
4) Note that the fee is applied for any hold placed
Signed-off-by: Sally Healey <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Cindy Murdock Ames <cmurdock@ccfls.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch adds the ability for a logged in user to pay fines and
fees from the OPAC via PayPal.
Test Plan:
1) Apply this patch
2) Create a paypal developer account
3) Create two test accounts, a Personal account and a Business account
4) Enable PayPal in Sandbox mode via the system preferences.
5) Enter the business account API credentials into the new system
preferences.
6) Create a new patron, add some fines/fees
7) Log in as that patron in the OPAC
8) Choose to pay via PayPal, log in as the sandbox Personal account
9) Complete the transaction
10) Note the fee is now paid
Signed-off-by: Carol Corrales <ccorrales@losgatosca.gov>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch gives patrons the option of allowing other
linked relatives to view his or her checkouts from
opac-user.pl in a manner similiar to the patron's own
checkouts tab. By default the setting is not enabled.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Create three borrowers, link them as relatives
4) In the OPAC, go to "my privacy" and choose to allow
relatives to view current checkouts for borrowers A and B
5) Check out some items to each borrower
6) Log into the OPAC as borrower A, you should see a "Relatives'
checkouts" tab. In this tab you should see the checkouts for
borrower B
7) Log into the OPAC as borrower C, you should be able to view
the current checkouts for both borrower A and borrower B
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
I have not tested this very thoroughly e.g. understood the SQL changes etc. since
the patch has been signed off twice before.
But it seems to me like this patch is OK.
Applied, ran automatic tests and saved some values in the overduerules matrix/tabs OK.
Signed-off-by: Eivin Giske Skaaren <eivin@sysmystic.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@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 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>
Title and description are updated separately, in case that the
library has changed one of them when editing the slip.
To test:
- Verify that you have a letter named 'Reserve Slip' in your database
- Run the database update
- Verify the slip has been renamed correctly
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Job done on a Koha English version. It won't hurt other langages
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Note: This feature depends on Bug 14870 'Delete C4/Dates from system'
System preferences:
To test:
- apply the patch
- run updatedatabase.pl
- go to Admin > Sysprefs > I18N, change dateformat to dd.mm.yyyy, save
- verify that the value was saved
Date handling:
- go through the staff client and verify that dates behave as expected.
- go through Opac and verify that dates behave as expected.
The Bugs where Bug 14870 depends on contain test plans that can be
used for the overall testing.
Note: Make sure that you reset the dateformat to the former value after
testing.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Works as expected
Amended to apply on top of Bug 15166 11.11.2015/mv
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>