The borrow permission was used but uselessly.
For instance, at the opac, the flagsrequired parameter was set to
'borrow' but the 'authnotrequired' was set also (which means no auth
required).
At the end, this permission was used at only 1 place: for the basket,
intranet side.
This can be replaced with the catalogue permission (which is used to
search).
Test plan:
1/ Confirm that you are able to show/download/sent the cart (intranet side)
with the catalogue permission.
2/ At the OPAC, you should be able to access the same pages as before
with any other permissions.
Concretely it is quite difficult to test this patch, you should have a
look at the code.
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
http://bugs.koha-community.org/show_bug.cgi?id=9987
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Having placed holds on Serial Items with an enumchron, and browsing the
opac-user.pl's "Holds"-tab, the user cannot see which numbers of
magazines/serials he has on hold.
This patch appends the koha.items.enumchron after the title component in the
opac-user.pl's Holds-view.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This is the same issue as bug 12134.
Test Plan:
1) Add a manual restriction to a patron with expiration date in the past.
2) Go on the OPAC and connect (opac-user.pl)
3) Note the warning message
"Your account has been frozen until until XX/XX/XXXX ..."
4) Apply this patch
5) Repeat step 2
6) Note the warning message does not appear anymore
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described.
NOTE: If you set a debarment with date in the past in the GUI,
there will be no entry in borrowers.debarred and you won't be
able to see the problem. Set one with a date in the future and
then alter the date in borrower_debarments and borrowers.debarred.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Matthias Meusburger <matthias.meusburger@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
- Use the shibbolethAuthentication syspref to enable Shibboleth authentication
- Configure the shibbolethLoginAttribute to specify which shibboleth user
attribute matches the koha login
- Make sure the OPACBaseURL is correctly set
BUG8446, Follow-up: Adds Shibboleth authentication
- Fix logout bug: shibboleth logout now occurs only when
the session is a shibboleth one.
- Do some refactoring: getting shibboleth username is now
done in C4::Auth_with_Shibboleth.pm (get_login_shib function)
BUG8446, Follow-up: Adds Shibboleth authentication
- Adds redirect to opac after logout
BUG8446, Follow-up: Adds Shibboleth authentication
- Shibboleth is not compatible with basic http authentication
in C4/Auth.pm. This patch fixes that.
BUG8446, Follow-up: Adds Shibboleth authentication
- Use ENV{'SERVER_NAME'} instead of syspref OpacBaseURL in order to work with
multiple vhosts.
BUG8446, Follow-up: Adds Shibboleth authentication
- Adds missing protocol for $ENV{'SERVER_NAME'}
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jesse Weaver <pianohacker@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested with the feide idp.
- LDAP login and logout are working
- local login/logout are still working
- CAS login/logout are still working
Instructions for setup can be found on the wiki:
http://wiki.koha-community.org/wiki/Shibboleth_Configuration
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch makes opac-user.pl and the bootstrap version of opac-user.tt
handle the new renewal errors "auto_renew" and "auto_too_soon".
To test:
1) Set global syspref "opacthemes" to bootstrap.
2) Set global syspref "OpacRenewalAllowed" to Allow.
3) Test the same things as in previous patch, this time for the OPAC
summary page.
Sponsored-by: Hochschule für Gesundheit (hsg), Germany
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Currently, when a patron renews an item via the opac, the only feedback
the patron receives when a renewal is successful is an updated value for
the due date of the item. This subtle indication of success may go
unnoticed by some patrons. We should add a more prominent way to
indicate an item was renewed successfully.
Test Plan:
1) Apply this patch
2) From the OPAC, renew some items
3) Note the "Renewed!" message in the "Renew" column of the checkouts table
Signed-off-by: Cathi Wiggins <cwiggins@ci.arcadia.ca.us>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script.
Makes successful renewals more visible to the user in the OPAC.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since we switched to Template Toolkit we don't need to stick with the
sufix we used for HTML::Template::Pro.
This patch changes the occurences of '.tmpl' in favour of '.tt'.
To test:
- Apply the patch
- Install koha, and verify that every page can be accesed
Regards
To+
P.S. a followup will remove the glue code.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds a line in opac-user.pl passing author info to opac-user.tt
Thanks to cait for helping me out and showing me how to solve this with half the amount of code.
Test plan:
* Reserve a book.
* Go to the opac and log in as the patron you reserved the book for.
* Apply the patch with change to opac-user.pl
* Revisit the opac and refresh it.
* See if author now shows up
Signed-off-by: Magnus Enger <digitalutvikling@gmail.com>
Created a hold. Author is not shown n the public catalogue before
applying the patch, but it does show after applying the patch. Way
to go, Viktor!
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
See comments 86 and 88. This patch fixes a bad conflict resolution in a
previous patch.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Some corrections :
- opac-reserve.tt : opening <p> instead of closing
- opac-user.tt : warnexpired was in database format, adds the use
of KohaDates template plugin
- opac-user.tt : duplicated TT test : [% IF ( BORROWER_INF.warnexpired ) %]
and [% ELSIF ( BORROWER_INF.warnexpired ) %], maybe a merge error
- opac-user.tt : <string> instead of <strong>, maybe for HTML 6 :-)
- opac-user.pl : adding dateformat var to template is already done by Auth.pm
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Testing notes:
- Database update
* Changes to kohastructure match changes done by the updatedatabase
statement. Feature is activated by default. Fixing 'yes' to be '1'
in a follow up.
* Ran database update succesfully.
* Note: Patrons are now blocked by default in new installations
AND in updated installations.
- System preference
* Verified system preference shows up correctly.
- Category configuration
* Add new patron category
* Edit existing patron category
* Delete patron category
* Check patron category summary table.
=> Verified all actions work as expected.
=> Verified chosen value for BlockExpiredPatronOpacActions'
is always displayed and saved correctly.
* Note: The new value is missing from the summary table.
* Note: The new value is also not shown when deleting a patron category.
- Check functionality
* Renew and place a hold for an NOT EXPIRED patron with
a) category: use syspref (default)
syspref: block (default)
b) category: use syspref (default)
syspref: don't block
c) category: block
syspref: don't block
d) category: block
syspref: block
e) category: don't block
sypref: block
* Verified renewals and placing holds were never blocked.
* Also verified that the warning from NotifyBorrowerDeparture
still shows up correctly.
* Renew and place a hold for an EXPIRED patron with
a) category: use syspref (default)
syspref: block (default)
=> OK, both actions are blocked.
b) category: use syspref (default)
syspref: don't block
=> OK, both actions possible.
c) category: block
syspref: don't block
=> OK, both actions are blocked.
d) category: block
syspref: block
=> OK, both actions are blocked.
e) category: don't block
sypref: block
=> OK, both actions possible.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
2014-04-06 Update: Will repeat and amend above test plan on last patch in this series.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
* Hide renewal column, buttons and links
* Fixes minor bug where upper-right table links would show even if
renewal impossible
* Cleans up some of the template formatting ( whitespace changes only )
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test Plan:
1) Apply patch
2) Run updatedatabase.pl
3) Pick a patron, note the patron's category
5) Issue an item to this patron
4) Edit that category, set "Block expired patrons" to "Block"
5) Verify the patron cannot renew or place holds in the OPAC
6) Edit the category again, set "Block expired patrons" to
"Don't block"
7) Verify the patron *can* renew and place holds in the OPAC
8) Edit the category again, set "Block expired patrons" to
"Follow system preference BlockExpiredPatronOpacActions"
9) Set the system preference BlockExpiredPatronOpacActions to
"Block"
10) Verify the patron cannot renew or place holds in the OPAC
11) Set the system preference BlockExpiredPatronOpacActions to
"Don't block"
12) Verify the patron *can* renew and place holds in the OPAC
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Melia Meggs <melia@bywatersolutions.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Testing notes on last patch in series.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch makes opac-user.pl and the bootstrap version of opac-user.tt
handle the new renewal error "too_soon".
To test:
1) Set global syspref "opacthemes" to bootstrap.
2) Set global syspref "OpacRenewalAllowed" to Allow.
3) Test the same things as in previous patch, this time for the OPAC
summary page.
Sponsored-by: Hochschule für Gesundheit (hsg), Germany
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This patch adds a more extensible and flexible debarments system to Koha. The fields
borrowers.debarred and borrowers.debarredcomment are retained for compatibility and
speed.
This system supports having debarments for multiple reasons. There are currently
three types of debarments:
OVERDUES - Generated by overdue_notices.pl if the notice should debar a patron
SUSPENSION - A punative debarment generated on checkin via an issuing rule
MANUAL - A debarment created manually by a librarian
OVERDUE debarments are cleared automatically when all overdue items have been returned,
if the new system preference AutoRemoveOverduesRestrictions is enabled. It is disabled
by default to retain current default functionality.
Whenever a borrowers debarments are modified, the system updates the borrowers debarment
fields with the highest expiration from all the borrowers debarments, and concatenates
the comments from the debarments together.
Test plan:
1) Apply patch
2) Run updatedatabase.pl
3) Verify the borrower_debarments table has been created and
populated with the pre-existing debarments
4) Run t/db_dependent/Borrower_Debarments.t
5) Manually debar a patron, with an expiration date
6) Verify the patron cannot be issued to
7) Add another manual debarment with a different expiration date
8) Verify the 'restricted' message lists the date farthest into the future
9) Add another manual debarment with no expiration date
10) Verify the borrower is now debarred indefinitely
11) Delete the indefinite debarment
12) Verify the debarment message lists an expiration date dagain
13) Enable the new system preference AutoRemoveOverduesRestrictions
14) Set an overdue notice to debar after 1 day of being overdue
15) Check out an item to a patron and backdate the due date to yesterday
16) Run overdue_notices.pl
17) Verify the OVERDUES debarment was created
18) Return the item
19) Verify the OVERDUES debarment was removed
20) Disable AutoRemoveOverduesRestrictions
21) Repeat steps 15 though 18, verify the OVERDUES debarment was *not* removed
22) Add issuing rules so that an overdue item causes a temporary debarment
23) Check out an item to a patron and backdate the due date by a year
24) Return the item
25) Verify the SUSPENSION debarment was added to the patron
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
In the OPAC, the patron summary page (opac-user.pl) should display
subtitle along with title in the lists of checkouts, overdues, and
holds. This patch adds it.
To test, log in to the OPAC as a patron who has checkouts, overdues, and
holds which include titles with subtitles. Titles should appear
correctly with and without subtitles.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Prior to this patch, if a patron has fines which exceed the limit set by
OPACFineNoRenewals but OPAC renewals are disallowed by OpacRenewalAllowed,
a message was displayed in their OPAC summary like this:
"Please note: You currently owe XXX in fines. Please pay your fines if you wish
to renew your books."
Information about outstanding fines in this case has no bearing on
how the user sees his summary of checkouts; since the user cannot
renew the loans from the OPAC regardless of their fine balance if
OpacRenewalAllowed is not enabled, this patch removes the message.
To test, try various combinations of OpacRenewalAllowed and
OPACFineNoRenewals with a patron who has outstanding fines:
- OpacRenewalAllowed ON and OPACFineNoRenewals ON (set to be triggered
by the test patron's fines): Logging in to the OPAC the patron should
see a warning on opac-user.pl about not being able to renew items
because of fines.
- OpacRenewalAllowed ON and OPACFineNoRenewals OFF (threshold high
enough not to trigger a block): No warning appears.
- OpacRenewalAllowed OFF and OPACFineNoRenewals ON: No warning appears.
- OpacRenewalAllowed OFF and OPACFineNoRenewals OFF: No warning appears.
If OpacRenewalAllowed is diabled and a patron's fines exceed the limit
set by OPACFineNoRenewals they should see no message.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passes koha-ql.pl and perlcritic
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
As QA followup on report 9722. Built on top of another followup report 10321.
Test plan:
Run the db revision included in the other patch.
Enable OpacHoldNotes. Check that you can add a hold note on opac-reserve.
Do you see it on opac-user and in staff on catalog detail of that biblio?
Do a grep on ShowHoldNotes on the Koha code: grep -i ignores case. You should
find three occurrences only in updatedatabase.pl (the old dbrev and this dbrev
renaming them). These are fine.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch rewrites the GetReserveStatus routine in order to take in
parameter the itemnumber and/or the biblionumber.
In some places, the C4::Reserves::CheckReserves routine is called when
we just want to get the status of the reserve. In these cases, the
C4::Reserves::GetReserveStatus is now called.
This routine executes 1 sql query (or 2 max).
Test plan:
Check that there is no regression on the different pages where reserves
are used. The different status will be the same than before applying
this patch.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Make charges of type FU be counted for opac-user.pl
Test Plan:
1) Checkout an item to a patron, back date the date due enough to create fines
2) Run fines.pl
3) Log into the patron's account via the OPAC
4) Note the fines line for that issue says 'No'
5) Apply patch
6) Reload opac-user.pl, not the fines column now says 'Yes'
Signed-off-by: David Cook <dcook@prosentient.com.au>
Works great, Kyle. Seeing as my test patron had $4500 in fines for that item, I was glad to see that column switch to "Yes" ;).
I'm not sure what the difference is between FU and F is, or what L means, but the patch works, so I'm signing off.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
This works as described, all tests and QA script are ok.
Note: why show yes and not the fine amount?
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Previously users would see the same message whether their card was about
to expire or was already expired. This patch adds a new message to
handle cards which are about to expire, following the
NotifyBorrowerDeparture system preference.
TEST PLAN :
The best way to test would to have at the same time :
- a SQL client to change the expiry date of a borrower
- an OPAC session opened for the same patron.
Case 1: expiry date is set in the future
-> no warning
Case 2: expiry date is set in the near future (within the
"NotifyBorrowerDeparture" system preference range)
-> a warning says the card will expire on **date**
Case 3: expiry date is set in the past
-> before patch, same warning as Case 2
-> after patch, new warning indicating that the card has expired
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Added description to the patch and copied test plan from the bug report.
Patch passes test plan.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Added RentalsInNoissueCharges and ManInvlsInNoissueCharges sys prefs
Created C4::Members::cwGetMemberAccountBallance()
* A wrapper for GetMemberAccountRecords that gives info on non-issue and
other charges
* Other charges are:
'Res'
'Rent' if RentalsInNoissueCharges is Mo
authorised_values MANUAL_INV if ManInvlsInNoissueCharges is No
C4::Members::GetMemberAccountRecords() changes:
* Dropped input param $date, it is not used
Use split charges in C4::Circulation::CanBookBeIssued() and
C4::Members::patronflags(). That way only fines decide whether an item
can be issued, and not other non-fine charges
Signed-off-by: Marc Veron <veron@veron.ch>
Rebased (updatedatabase.pl)
ManInvInNoissueCharges and RentalsInNoissueCharges ar both included by default (= behaviour as before)
All variants tested: Both included, none included, manual invoice included, rentals included.
Works fine, blocks/does not blok as appropirate, messages appear as expected.
[Oct 12, 2012 marcelr:] Amended for updatedatabase.pl
Signed-off-by: M. de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
- the dateformat value is send to all templates (from
C4::Auth::get_template_and_user)
- remove all assignment of dateformat in all .pl files
- the DHTMLcalendar_dateformat variable is unused
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixed conflicts:
- opac/sco/sco-main.pl
- reports/acquisitions_stats.pl
- tools/cleanborrowers.pl
All tests pass, perlcritic problems appeared in some files
before and after these patches were applied.
Checked sorting in following pages:
- acqui/addorderiso2709.tt - list of staged imports in acq
- acqui/histsearch.tt - sorting of dates in acq search result list
- acqui/invoices.tt - billing date in list of invoices in acq
- acqui/lateorders.tt - list of late orders in acq
- acqui/ordered.tt - ordered titles and estimated costs for a fund
- acqui/parcels.tt - receive shipment page
- acqui/spent.tt - received titles and actual costs for a fund
...
- serials-search.tt - subscription search result list
...
- opac/sco/sco-main.tt - due dates in list of checked out items
- reports/acquisitions-stats.tt - date searches, display of dates
- tools/cleanborrowers.tt
- tools.holidays.tt - different views of dates library is closed,
adding dates
Checked dates display according to system preference everywhere and
searching, entering dates etc. still worked as expected.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch removes the superflous code related to 'publictype' which
is a key set for item hashes in some perl files. This key is never
used or stored.
Test Plan:
1) Apply patch
2) Test catalogue/detail.pl, opac/opac-detail.pl and opac/opac-user.pl
3) You should not see any changes in behavior
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This development will add the ability for a new patron to register
himself or herself. The self-registration will attempt to match this
newly inputted data to any existing patrons and if any possible matches
are found, ask if the patron is sure he or she doesn't already have an
account at the library. A system preference may be set to prevent patron
self-registration if the system detects the possibility that the person
may already have an account.
Once the patron has registered, passing a captcha (or similar
bot-stopper), the patron will then be optionally verified a second time
via email. At this point, the patron will be able to print a temporary
library card (optional by system preference), and will be provided any
details necessary to access electronic resources (this body of text
would be a template in the slips and notices system). At the library's
choice, this new patron would either be set to a temporary patron status
(patron type set via system preference), or a fully-fledged patron
(allow patron type to be determined by age and/or other attributes).
Assuming the library uses temporary patron types for OPAC registrations,
this patron will next enter a queue and would need to physically enter
the library to verify himself and become a fully-fledged patron (most
likely by bringing in physical proof of address, etc.). The librarian
would look up the patron record and modify the patron type. If a
temporary patron has not been verified within a certain time frame
(defined by a system preference), the patron record will be deleted
from the system via a cron job.
For registered patrons, the system will allow each person to also
update his or her personal data via the OPAC. When a patron updates his
or her information, the changes will be entered into a queue to be
verified by a librarian (preventing a patron from inputting obviously
bogus data). The staff client home page will display the number of
patron records with changes awaiting approval. A librarian would then be
able to click through a list of modification requests, and approve or
deny each (with approval and denial alerts being sent to the patron via
the standard messaging system).
NEW SYSTEM PREFERENCES
* PatronSelfRegistration
* PatronSelfRegistrationDetectDuplicates
* PatronSelfRegistrationVerifyByEmail
* PatronSelfRegistrationPrintTemporaryCard
* PatronSelfRegistrationUseTemporaryStatus
* PatronSelfRegistrationExpireTemporaryAccountsDelay
NEW NOTICE
* Verify by email notice
NEW SLIP
* Temporary card slip
NEW CRON JOB
* delete_expired_opac_registrations.pl
- Deletes patrons that have not been upgraded from the temporary
status within the specified delay
* delete_unverified_opac_registrations.pl
- Deletes the unverified patrons based on the length of time specified
in the PatronSelfRegistrationExpireTemporaryAccountsDelay
The patron will register from self_registration.pl, linked off opac-main.pl if enabled. The registration page will be translatable to other languages in the same way that existing templates are.
Test Plan:
1) Enable PatronSelfRegistration
2) Set PatronSelfRegistrationExpireTemporaryAccountsDelay to a number
of days
3) Create a self-registered borrower category
4) Set PatronSelfRegistrationUseTemporaryStatus
5) Set PatronSelfRegistrationVerifyByEmail to "Don't require"
6) Go to OPAC, log out if logged in.
7) You should see the "Register here" link below the login box
8) Attempt to register yourself
9) Verify you can log in with your temporary password.
10) Set PatronSelfRegistrationVerifyByEmail to "Require"
11) Attempt another self-registration
12) Check the messages table, you should see a new message with a
verification link.
13) Copy and paste the link into a web browser to verify the registration
14) Log in with the given credentials to verify the account was created.
Test Plan - Part 2 - Borrower Modifications
1) Log in to OPAC, go to "my personal details" tab.
2) Make some modifications to your details.
3) Repeat steps 1 and 2 for two more borrowers.
4) Log in to Koha intranet with a user that can modify borrowers.
5) At the bottom of mainpage.pl, you should see:
Patrons requesting modifications: 3
6) Click the link
7) Approve one change, deny a different one, and ignore the third, then
submit.
8) Check the records, you should see the changes take affect on the
approved one, and no changes to the other two. You should also see
"Patrons requesting modifications: 1" at the bottom of mainpage.pl
now.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Bug 7067 - OPAC Borrower Self Registration - Followup
* Rename PatronSelfRegistrationUseTemporaryStatus to PatronSelfRegistrationDefaultCategory
* Hide register link unless PatronSelfRegistrationDefaultCategory is set.
* Add invalid token page
* Add documentation and switches to cron scripts
* Add required fields check for editing exiting patrons
* Don't force require email address for existing patrons when
PatronSelfRegistrationVerifyByEmail is enabled.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Passed-QA-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
There was a bunch of tabulations from line 157 and followings
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
The following command show us there is no change:
git show HEAD --ignore-all-space
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
If OpacRenewalAllowed is set to "Don't allow" and OPACFineNoRenewals is set to blank ( i.e. disabled ).
A user who owes any fines, when logged in to the OPAC will receive the following message:
Please note: You have more than 0.00 in fines.
This is a rather odd message, and is not very sensible. The message should either be modified or removed altogether.
This patch modifies the message to the following:
Please note: You currently owe $fines in fines
where $fines in the formatted amount the borrower currently owes
in fines.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
New syspref is Choice, options being:
- None
- Priority only
- Holds number only
- Holds number and priority
Show holds count on OPAC detail
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Adds the ability to suspend reserves. The new system preference
AutoResumeSuspendedHolds enables the ability to set a date for
a suspended hold to automatically be resumed.
When a hold is suspended, it will continue to increase in priority
as the holds above it are fulfilled. If the first holds in line
to be filled are suspended, the first non-suspened hold in line
will be used when an item can fulfill a hold that has been placed.
http://bugs.koha-community.org/show_bug.cgi?id=7641
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Tested with the preference on and off:
1. placed several holds in the staff client
2. suspended some with a date
3. suspended some without a date
4. triggered hold message by checking in for hold with suspensions
5. the suspended hold was skipped as it should be
6. tested suspending holds in the OPAC w and w/out dates
7. ran the cron to clear suspensions with dates
All the above tests worked as expected. Signing off.
Removes the textmessaging parameter from opac/opac-main.pl and
opac/opac-user.pl, since it's not utilized anywhere in the templates, and is
sourced from a field that no longer exists in the borrower
table (textmessaging).
This also removes a dependency on C4/Members.pm from opac-main.pl
To Test: Login to the OPAC, and view both opac-user.pl and opac-main.pl. Both
pages should still render properly.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
If the book is due at 23:59 the due time is irrelevant
and potentially confusing to the user add a DateUtils
routine that strips that off the returned display date
While it should be impossible now to have a patron without expiry date, I still had one. It does not hurt to add a simple check on expiry date defined before calling delta days on null values and breaking the opac login.
Trivial change.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested by deleting the expirydate from my own patron record.
Missing expiry date now no longer breaks the summary page
in the patron account on OPAC.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
This patch standardizes the condition under which renewal controls
are displayed at the page (as opposed to item) level. In some
places "canrenew" was used, in others "patron_flagged" was used.
Now "canrenew" controls renew controls and "patron_flagged" only
triggers the display of user warnings.
This patch also allows for renewal information to be displayed
for each item in situations where OPAC renewals are allowed but
disabled for whatever reason. This gives the patron information
about used/available renew counts but hides renew controls.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
This patch copies the debarred handling method from circulation.pl for
use on opac-user.pl so that debarred dates and comments can be handled
properly.
I have slightly reworded the message in the OPAC and on circulation.pl
to make the display of the debarred comment a little clearer.
Revision adds missing handling of debarred status with regard to
renewal operations. Renew links and buttons were not being hidden
from debarred users.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Renewal buttons are gone, message looks good.
liz@koha-deb:~/kohaclone$ prove xt
xt/permissions.t .. ok
xt/tt_valid.t ..... ok
All tests successful.
Files=2, Tests=27, 9 wallclock secs ( 0.05 usr 0.01 sys + 8.28 cusr 0.08 csys = 8.42 CPU)
Result: PASS
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
To test:
Create 4 holds on a bib, for patrons A, B, C, and D,
Check in the item to mark hold as waiting for patron A
Check out the item to patron B -> reserve for patron B should be removed
Check in the item to mark hold as waiting for patron A
Check out the item to Patron A, hold should complete normally
Check in the item to mark hold as waiting for patron C
Check out the item to patron D -> reserve for patron D should be removed.
Check in the item to mark hold as waiting for patron C
Check out the item to patron C, hold should complete normally
Check in the item -> there should be no more reserves.
We also tested:
Created 4 holds on a bib with two items, for patrons A, B, C, and D
All worked as expected.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Some code coming from BibLibre has been lost in the process of inclusion in
3.4. The result is that fine in days does not work at all (you can setup rules,
but it does nothing)
Step to reproduce:
- Koha > Admin > circ rules > set 1 day fine every day of overdue for default
rule
- Issue a book return date last week
- check-in the book => no debarment is set
The following patch will fix all of those problems by :
* updating borrowers.debarred to a date field (instead of tinyint). It contains
the limit of the debarment
* changing API of DebarMember and UpdateBorrowerDebarred to pass a date
* display debarrdate where applicable. Note that a debarrdate of 31/12/9999 is
considered as unlimited and not displayed
* added a debarrcomment, usefull to explain why a patron is debarred (this is
independant from debarrdate changes and can be used when placing an unlimited
debarment too)
[2011-05-12] F. Demians. It works as described. And I can confirm this
functionality is impatiently awaited by French libraries since one year. Thanks
BibLibre for the good work and for contributing this code.
Bug 6328 Followup--update DB structure
Thanks Katrin.
Bug 6328: make comment a textbox / fix debar by notice trigger
Debarring by notice triggers was broken, because the new function
expects a date as second parameter.
The comment field in patron account details was a very long text field.
Patch changes it to be a textbox instead.
Bug 6328: Lift debarment leaves patron account
'Lift debarment' redirects to an empty circulation page.
BZ6328 follow-up 3
Fixes comment 23 from Fernando L. Canizo : when the patron was debarred and debar removed
he still could not check-out.
The changes in the IsMemberBlocked (that were on biblibre/master) were lost somewhere
The sub was still checking for old_issues instead of calling CheckBorrowerDebarred
to get a debardate if applicable
Note : this bug was appearing only is you had issuing rules defined for itemtype/categorycode/branch.
Seemed to work if you had only default rules. That's probably why it hadn't been spotted before
BZ6328 follow-up 4
Comments fron Zeno Tajoli: The patch is OK and I sign-off it. Two little changes done on
installer/data/mysql/kohastructure.sql and installer/data/mysql/updatedatabase.pl
Signed-off-by: koha <koha@kohabase.localdomain>
