Minor changes to pay.pl and paycollect.tt to allow writing off a partial amount of a fine.
Test plan:
0) Go to the Fines tab of a test patron's profile
1) Create a fine if there are none (under the Manual invoice tab)
2) Go to the "Pay fines" tab
3) Press the write off button on the corresponding account line
Without patch, you'll be asked to confirm, but will not be able to edit the amount
With patch, you'll be able to edit the amount.
Followed test plan, patch worked as described. Also ran QA test tool and
modified files passed
Signed-off-by: Simon Pouchol <simon.pouchol@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Previous changes were wrong, the notify_id was always equal to 1 and
GetBorNotifyAcctRecord was used to retrieved the account lines to pay
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It appears that has never worked.
Could someone confirm?
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Modified pages:
circ/circulation.pl
circ/circulation_batch_checkouts.pl
members/boraccount.pl
members/files.pl
members/holdshistory.pl
members/housebound.pl
members/moremember.pl
members/notices.pl
members/purchase-suggestions.pl
members/readingrec.pl
members/routing-lists.pl
members/statistics.pl
Test plan:
0) Do not apply the patch
1) Have a patron with title/salution filled in
2) Confirm bug, go for example to circ/circulation page and see there is
html in <title> tag (you can see it in your browser page/window title)
3) Apply the patch
4) Go through circulation/patron pages (see modified page above) and
confirm there is no html in <title> tag, but on the page itself the
salutation should be in <span class="patron-title">
Signed-off-by: David Bourgalt <david.bourgault@inlibro.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Our librarians requested a reminder to unset "gone no address" flag from patron's
record once the patron has made a modification request to update their address.
I propose adding a message box under patron modification request to notify
librarians about patrons that have gone no address flag on, and an option to
unset the flag without the need of having to navigate into patron's details.
To test:
1. Apply patch
2. Set "Gone no address" flag for your test patron. You can do this by going
to patron modification screen in staff client.
3. Go to OPAC with your test patron
4. Make a modification request for your personal details
5. Go to staff client and see pending modification requests
6. Open the request you just created
7. Observe a message dialog that says this patron has gone no address flag set
8. Check the checkbox to unset the flag and approve the modification request
9. Click Submit
10. Observe your test patron no longer has gone no address flag set
11. Repeat steps 2-7
12. Do not check the checkbox, but approve the modification request
13. Observe your test patron still has gone no address flag set
14. Remove the gone no address flag from your test patron
15. Repeat steps 3-6
16. Observe there is no message dialog for gone no address
Followed test plan, patch worked as described. Also ran QA test tools
and all modified files passed
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch fixes the status showed in holds history table.
The determination of status is following:
1. "hold.found is 'F'" - Fullfilled - the hold was fullfilled by checking the
item to patron. If hold reaches this state, it can't changed status
anymore, or be cancelled, that's why this goes first
2. "hold.cancellationdate is filled" - When the hold is cancelled, its
eventually waiting or in transit status remains the same, only
cancellation dat is filled, so this has to go second
3. "hold.found is 'W'" - Hold is waiting
4. "hold.found is 'T'" - Hold is in transit to target library
Test plan:
0) Apply the patch
2) Read the status determination note in this commit message and confirm
it makes sense
1) Have patron/patrons with at least one hold in every status
2) Go to holds history page and confirm it show the right status
3) Try to break the status determination ;)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
- Adds 'holds' to pref description of intranetreadinghistory
- Fixes typo in link to holds history from patron account
- Changes reserve date to hold date in table heading
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
0) Have a patron with some current and old reserves
1) Go to patron circulation page
2) Notice, there is new item called "Holds history" in the left
circulation menu
3) Go to this page and confirm the data on this page are OK, and that
ui does behave as expected
4) Go to adminitration, columns setting, try to change the setting for
holdshistory table and confirm it is taken into account on holds history
page
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It seems better to display the warning if the user tries to enter too
many characters in the input.
Test plan:
With max=16
1. Copy/paste a string with 15, 16 and 17 characters
2. Enter a cardnumber of 15, 16, 17 characters
The warning should be displayed only the input overflows
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch displays a message if the user tries to enter more than the
max number of characters for a cardnumber.
To test:
1) Apply patch and go to Patrons -> New patron
2) Scroll down to Card number
3) Put in any characters. Notice that when you have entered the max
number of characters, you are unable to type any more.
4) Click out of the text field (so it loses focus), the error message will show up.
5) if you backspace some characters and click out of the text field
again, the message should disappear
Sponsored-by: Catalyst IT
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>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The form provided on top of the page if Koha find a duplicate
patron is not closed. This cause some trouble.
Test plan:
- Edit the syspref IntranetUserJS and type the following code:
"$(document).ready(function() {
$("#memberentry_library_management").insertBefore("#memberentry_identity");
});"
- create a patron so that Koha will warn you about a duplicate one,
- click on "Not a duplicate. Save as new record",
- you should get error(s) about empty field(s).
Note that now, the library management part's fields are empty or
reset to default
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Security bug, trivial changes, no need to provide procedure for script
kiddies.
Test plan:
Pay fines using the different options from the "Pay fines" tab.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Now that we have a check client-side, nothing prevents us from a smart guy to
bypass it and force an invalid password.
This patch adds two new subroutines to Koha::AuthUtils to check the
validity of passwords and generate a password server-side. It is used
only once (self-registration) but could be useful later.
Moreover the 3 different cases of password rejection (too leak, too
short, contains leading or trailing whitespaces) were not tested
everywhere. Now they are!
This patch makes things consistent everywhere and clean up some code.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The length of the passwords generated for a patron should not be as long
as the value of minPasswordLength.
It is the minimum required size of a password, not the maximum!
So let's fix it to 8 if the minPasswordLength if < 8, that sounds
reasonable and less risky for patrons.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Indeed if RequireStrongPassword is set we need at least 3 characters to
match 1 upper, 1 lower and 1 digit.
We could make things more complicated to allow minPasswordLength < 3
but, really, 3 is already too low...
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch removes a really ugly way to generate a password: the whole
template was sent and parsed to retrieve the "#defaultnewpassfield" node.
To avoid the password to be sent plain text it is certainly better to
generate it client-side.
The same kind of passwords will be generated: 0-9a-zA-Z
The while loop prevents to get an invalid generated password.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To validate password fields we need to use the validate jQuery plugin.
To make things reusable this patch adds a new include file
'password_check.inc' at the intranet and opac sides, it creates 3 new
validation methods:
- password_strong => make sure the passwords are strong enough according
to the values of the RequireStrongPassword and minPasswordLength prefs
- password_no_spaces => prevent passwords to be entered with leading or
trailing spaces
- password_match => make sure both password fields match
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There are other scripts where the borrower variable is not defined and
the fields are passed one by one.
To have a consistent behaviour we should add the title at the different
places.
Note that this script also add the use of the include file for
statistics.tt and remove the pass of parameters to the template, already
done later:
99 $template->param(%$borrower);
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In preparation to test this patch:
- Add a patron list named <script>alert("patron list")</script>
- Add a library named <script>alert("library")</script>
- Add a patron category named <script>alert("patron category")</script>
To test:
- Access patron search page and do a search
- Verify that the alerts added above are executed
- Apply patch
- Verify that no alerts are displayed
Signed-off-by: Amit Gupta <amit.gupta@informaticsglobal.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test
1/ hit /cgi-bin/koha/members/member.pl?&searchmember=<script>alert('XSS Payload')</script>
2/ Notice js is executed
3/ Apply patch, reload
4/ js is now escaped
Signed-off-by: Amit Gupta <amit.gupta@informaticsglobal.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
1. Create a patron category with the dateexpiry value of 29/9/2017
2. Create a patron user from that patron category (which I'll refer to as patron A) with the date
expiry value of 1/10/2017 and submit the form
3. Notice that the manual dateexpiry you have submitted is correctly
displayed
4. Create a duplicate patron with the same firstname and surname and
patron A, and set the date expiry value of 1/10/2017 and submit the form
5. The form displays a duplicate patron message. Notice that the dateexpiry input box is empty now
6. Select the new member (not a duplicate member) option in the
messagebox
7. The form successfully submits and notice that the date expiry value
displayed is that of the patron category (i.e. it is 29/9/2017) not the
dateexpiry value of 1/10/2017 that you manually set for this patron
8. Apply patch
9. Repeat step 4
10. The form displays a duplicate patron message. Notice the dateexpiry input box still
contains the value you entered which is 1/10/2017. Select the new member
(not a duplicate member) option in the messagebox
11. The form successfully submits and notice that the date expiry value
displayed is 1/10/2017 that you manually set for this patron
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Adds logic from the previous fix to the brief patron summary
shown when checking a possible patron duplicate.
Bonus: Also fixes missing patron category description there.
To Test:
- Add 2 patrons
- Add a patron with the same surname and firstname as an
existing patron in order to trigger the duplicate message
- Click "View existing patron"
- Verify display is correct when existing patron is
- an organisation
- not an organisation
- Verify that the patron category description shows
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Problem: A patron category "I" would cause display problems
on the details in the intranet. This is because the templates
confused patron category "I" with patron type "I" (organisation).
Patch:
- Cleans up variable confusion between categorycode and
categorytype.
- The template contained code to change the labels below
the address to 'Organisational phone:" etc., I have removed
this part as it does not match the edit form anymore.
- Initials, date of birth and gender are still hidden for
organisation - matching the edit form.
Bonus:
- The patron category description was missing on the
right and left side of the details tab. Now it displays.
- Fixes some html issues:
- doubled up class attribute in a tag
- doubled up </li></li>
To test:
- Create 3 patrons
- patron category code doesn't matter, but category type organisation
- patron category code 'I', category type NOT organisation
- patron category code NOT I, category type NOT organisaton
- Check details tab in patron account in staff for all 3
- Verify patron category description shows correctly
- Verify information added to the account displays correctly
(phone numbers, emails, ...)
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The "Pay selected" option on the Fines tab in the borrower account page doesn't work as intended.
The fine on top of the list gets the amount deducted, even if another fine is choosen from the list.
Test Plan:
1) Create two or three fines, using the Create manual invoice function.
2) Choose one of the fines (not the one on the top) and click Pay selected
3) Pay a partial amount
4) Go back to the Pay fines tab an notice that the fine you selected has not changed. Instead, either the top fine or the total (see attachment) has ben affected.
5) Apply this patch
6) Repeat steps 1-3
7) Note the correct fine is paid
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
1. Hit /cgi-bin/koha/members/memberentry.pl?op=add&guarantorid=xx<script>alert('amit')</script>
xx - is a guarantorid
2. Notice the java script is executed.
3. Apply patch.
4. Reload page, and hit the page again /cgi-bin/koha/members/memberentry.pl?op=add&guarantorid=xx<script>alert('amit')</script>
xx - is a guarantorid.
5. Notice it is no longer executed.
NOTE: I had to test in Microsoft Edge, because Chrome was blocking XSS for me.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is a recurrent bug we have over the last years. When a script is
called with non-existent borrowernumber it will crashes.
We need to handle this gracefully instead of letting the script crashes.
On bug 18403 a new subroutine is added to the codebase
(output_and_exit_if_error) to handle this kind of errors correctly.
Since it is not pushed yet, I propose to just redirect to a script that
handle it correctly (circulation.pl) instead of adding this message to
all these scripts.
Test plan:
Hit different scripts from the members module and pass a non-existent
borrowernumber.
You must be redirected to circulation.pl with a friendly message.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Restore datepicker class
Use Koha.Preference
Copy changes to moremember
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There are some more files that expose parts of tt diretives to translations, mostly due to
line breaks inside directives.
Files covered with this Bug:
koha-tmpl/intranet-tmpl/prog/en/includes/authorities-search-results.inc
koha-tmpl/intranet-tmpl/prog/en/includes/circ-menu.inc
koha-tmpl/intranet-tmpl/prog/en/includes/search_indexes.inc
koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/issuehistory.tt
koha-tmpl/intranet-tmpl/prog/en/modules/intranet-main.tt
koha-tmpl/intranet-tmpl/prog/en/modules/members/members-update.tt
To test:
- Review code, verify that line breaks are removed
- Run QA tools
- Bonus test: Create a "language" aa-AA and verify that no fragments
containign %%] are picked for the 6 files
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Bug 18551 moves the way the filters are displayed and so the position of
the patron toolbar must be recalculated.
Test plan:
Edit patron's detail
open the filters, scrolldown
close the filters, scrolldown
=> The toolbar must be correctly placed
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
This patch adds a JavaScript confirm to the deletion of files. It also
styles the file deletion link as a Bootstrap button.
To test, apply the patch and open the "Files" page for a patron who has
files attached.
- Verify that clicking any "delete" link prompts for a confirmation.
- Verify that confirming the dialog triggers the deletion of the correct
file.
- Verify that canceling the confirmation dialog aborts the deletion.
- Confirm that the "Delete" button looks correct.
Signed-off-by: David Roberts <david.roberts@ptfs-europe.com>
Revision for QA: Replaced '.click(function' with '.on("click",function'
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Translation for memberentrygen.tt exposes a lot of template directives
like the following:
[% UNLESS opduplicate %][% othernames | html %][% END %]
Translators should not be confronted with such code internals.
To test:
- Review code changes
- Verify that creating / editing patrons works as before
- Bonus test: Create a "language" aa-AA (perl translate create aa-AA
from folder misc/translator, verify that lines like mentioned above
do no longer appear in aa-AA-staff-prog.po
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Fill out some fields in quick add
2 - Switch to full form and clear fields
3 - Switch back and fields are still populated
4 - Fill a field in long form
5 - Switch to quick add and clear it
6 - Save
7 - Value set in 4 is saved
8 - Apply patch
9 - Repeat 1-6 - values should be cleared and not saved
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>
To test:
1 - Add password to BorrowerMandatoryField
2 - View quick add form
3 - See confirm password twice
4 - Apply patch
5 - See confirm password once
6 - Add password to QuickAddFields
7 - Confirm one confirm field
8 - Remove password form BorrowerMandatory field
9 - Confirm there is one confirm field and password fields are not
required
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Test plan:
The same as first patch, but also with advanced search form in header hidden
on page load - see comment 4
Issue with advanced search form is gone.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Philippe <philippe.audet-fortin@inlibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
In member search page, the result table is in Ajax so fully managed by Javascript. There is also a yellow dialog message prepared in HTML.
Thoses elements are hidden by JS code : ie $("#patron_list_dialog").hide().
The problem is that the static page is first loaded an displayed then the JS code runs an hides the elements.
On a low performance computer, this action is visible and looks like there is a blinking yellow message.
I propose to hide with CSS so that thoses elements are not displayed in static page and are there shown in dynamic JS code.
Test plan :
Check display is unchanged :
- Go to home page /cgi-bin/koha/members/members-home.pl
- Perform patron search from header search box
- Perform patron search by clicking on a letter
- Perform patron search from filters (left of results table)
- Select a patron and add it to a list => you see the yellow message
Yellow message does no longer appear with this patch.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Philippe <philippe.audet-fortin@inlibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The function that switches between quick add/fulll form assumes labels
are followed by values - patron_attr don't follow this pattern. This
patch just moves the hidden input field
To test:
1 - Have some patron attributes (with/without auth values set)
2 - Add them to QuickAddFields (patron_attr2 for example)
3 - view quick add form and set some values
4 - Switch to full form, values not transferred
5 - Switch to quick add, view values, save
6 - Values are not saved :-(
7 - Apply patch
8 - Repeat 3 - 5
9 - Values are transferred and saved :-)
Signed-off-by: Peggy Thrasher <p.thrasher@dover.nh.gov>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Not the opac because we do not want the patron to modify it, they won't
be necessary translated.
Sponsored-by: Orex Digital
Signed-off-by: Hugo Agud <hagud@orex.es>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When a column is hidden by default on the patron search result table,
if the logged in user does not have the "tools > manage_patron_lists"
permission, the wrong column will be hidden.
Test plan:
Edit the column visibility detail for "Patrons > id=memberresultst"
Set "Fines" hidden by default
Search for patrons
=> Without this patch, if the logged in user does not have the
manage_patron_lists permission, the wrong column will be
hidden/displayed.
Signed-off-by: Séverine Queune <severine.queune@bulac.fr>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1 - Have no clubs
2 - View Details tab for a patron
3 - Note the 'Loading' tag near the tabs
4 - Apply patch
5 - Load patron details and notice 'Loading' is gone
6 - Add a club and verify tab shows as expected
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>
This features would add the ability to create clubs which patrons may be
enrolled in. It would be particularly useful for tracking summer reading
programs, book clubs and other such clubs.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Ensure your staff user has the new 'Patron clubs' permissions
4) Under the tools menu, click the "Patron clubs" link
5) Create a new club template
* Here you can add fields that can be filled out at the time
a new club is created based on the template, or a new enrollment
is created for a given club based on the template.
6) Create a new club based on that template
7) Attempt to enroll a patron in that club
8) Create a club with email required set
9) Attempt to enroll a patron without an email address in that club
10) Create a club that is enrollable from the OPAC
11) Attempt to enroll a patron in that club
12) Attempt to cancel a club enrollment from the OPAC
13) Attempt to cancel a club enrollment from the staff interface
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Current jQuery is not unhiding resend button, this patch adds an id
and a toggle command
To test:
1 - Enable EnhancedMessagingPreferences
2 - Find a patron with sent or failed messages
3 - Note you can expand message, but not resend
4 - Apply patch
5 - Note that on expanding message a 'Resend' button appears
6 - Ensure resend button operates as expected
Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Lari Taskula <lari.taskula@jns.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
