We are passing the Koha::Patron::Category object to the template instead
of the categorycode.
To reproduce this bug you must test in a system which has only one
patron category of the "adult" type. View the details of a patron with a
child-type patron category and choose More -> Update child to adult
patron.
This results in an error:
Can't call method "category_type" on an undefined value at
/home/vagrant/kohaclone/members/update-child.pl line 84.
The URL of the error page shows a problem with the parameters being
passed:
members/update-child.pl?op=update&borrowernumber=12345&catcode=Koha::Patron::Category=HASH(0xa168a18)&catcode_multi=
Test plan:
Make sure you have only 1 adult patron category
Update a child to adult
=> With this patch applied the error is gone and the patron has been
correctly updated
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Patch applies without issue and functions as described.
Signed-off-by: Dilan Johnpullé <dilan@calyx.net.au>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
To avoid $account, $accounts and @accounts variables in the same scope
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
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>
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>
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>
If someone decide the reuse the template->param statement to pass values
to the template, we will get the same issue.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If the logged in patron does not have the necessary permission we should
not redirect to circulation.pl but moremember.pl instead
Test plan:
With the borrowers permission, you should be able to edit a patron and
be redirect to the moremember page
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@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>
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>
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>
Due to the way members-home.pl handles the variable $branch, the number
of patron modifications listed on members-home.pl may differ from the
number listed on mainpage.pl. When the librarian clicks this link, he or
she may see a different number than was listed, or none at all!
Test Plan:
0) Set IndependentBranchesPatronModifications = Yes
1) Create a number of modification request for BranchA
2) Log into the staff intranet with a patron without superlibrarian
permissions and set your branch to BranchB
3) Note the modifications alert to does not display on mainpage.pl
4) Click the "Patrons" link to take you to members-home.pl
5) Note the modifictions alert does display on this page
6) Apply this patch
7) Reload members-home.pl, note the alert no longer displays
QA notes: What was the point of the branch variable?
Followed test plan, patch worked as described. Also passed QA test tool
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The following warn is triggered when I click the Reverse button next to
an individual payment on the Account tab:
CGI::param called in list context from package
CGI::Compile::ROOT::home_vagrant_kohaclone_members_boraccount_2epl line
63, this can lead to vulnerabilities. See the warning in "Fetching the
value or values of a single named parameter" at /usr/share/perl5/CGI.pm
line 436.
To test:
1) Go to a members detail page in staff side, create a manual invoice,
pay it
2) Go to the Account tab, click Reverse next to the payment you just
made
3) Notice warns
4) Apply patch and repeat steps 1 & 2
5) Warns should be gone
Sponsored-by: Catalyst IT
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The following warns are triggered when I click the Pay selected button:
CGI::param called in list context from package
CGI::Compile::ROOT::home_vagrant_kohaclone_members_pay_2epl line 267,
this can lead to vulnerabilities. See the warning in "Fetching the
value or values of a single named parameter" at
usr/share/perl5/CGI.pm line 436.
CGI::param called in list context from package
CGI::Compile::ROOT::home_vagrant_kohaclone_members_pay_2epl line
273, this can lead to vulnerabilities. See the warning in "Fetching
the value or values of a single named parameter" at
/usr/share/perl5/CGI.pm line 436.
To test:
1) Go to a members detail page in staff side and create a manual
invoice
2) Go to the pay fines tab, select the fine you just created and click
Pay selected
3) Notice warns
4) Apply patch and repeat steps 1 & 2
5) Warns should be gone
Sponsored-by: Catalyst IT
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The following warns are triggered when I click the Write Off button next
to an individual fine or charge:
CGI::param called in list context from package
CGI::Compile::ROOT::home_vagrant_kohaclone_members_pay_2epl line 171,
this can lead to vulnerabilities. See the warning in "Fetching the
value or values of a single named parameter" at
/usr/share/perl5/CGI.pm line 436. (this shows many times)
Use of uninitialized value in subroutine entry at
/usr/share/perl5/URI/Escape.pm line 184.
To test:
1) Go to a members detail page in staff side and create a manual
invoice
2) Go to the pay fines tab, click the Write off button next to the
invoice you just created
3) Notice warns
4) Apply patch and repeat steps 1 & 2
5) Warns should be gone
Sponsored-by: Catalyst IT
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1) Go to a members detail page in staff client
2) Select the Fines tab in the left pane
3) Select the Create manual invoice tab below the button menu bar
4) Create a fine and click save (e.g. Type: Fine, Amount: 5.00)
5) Select the Pay fines tab below the button menu bar
6) Click Pay on the item
7) Blank the staff error log
8) click confirm
-- staff error log has message
9) apply this first patch
10) repeat steps 3-8
-- staff error log is blank
11) run koha qa test tools
Sponsored-by: Catalyst IT
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
Using the pay selected option from the borrowers account, to pay for one specific fine among other gives a 500 error, despite the payment going through.
Test Plan:
1) Add two fines using the Create manual invoice function.
2) Select one fine and "pay selected".
3) Pay a part of the amount.
4) Note error
5) Apply this patch
6) Repeat steps 1-3
7) No error!
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
1. Hit /cgi-bin/koha/members/moremember.pl?borrowernumber=xx<script>alert('amit')</script>.
xx - is a borrowernumber
2. Notice the java script is executed.
4. Apply patch.
5. Reload page, and hit the page again /cgi-bin/koha/members/moremember.pl?borrowernumber=xx<script>alert('amit')</script>.
xx - is a borrowernumber.
6. Notice it is no longer executed.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
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>
To test:
1) Look at intranet log
2) Go to delete a debarment on a borrower
3) Notice warn
4) Apply patch
5) Add a new debarment
6) Delete this debarment
7) Notice warn is gone
Sponsored-by: Catalyst IT
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
GetMember returned a patron given a borrowernumber, cardnumber or
userid.
All of these 3 attributes are defined as a unique key at the DB level
and so we can use Koha::Patrons->find to replace this subroutine.
Additionaly GetMember set category_type and description.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch replace the different calls to GetReservesFromBorrowernumber
with a calls to Koha::Patron->get_holds.
In some places we need to get a restricted set of holds, that's why we
process a search on this holds returned by ->get_holds (on the found
status for instance).
The changes are quite trivial and reading the diff should be enough to
catch bugs.
Test plan:
I would suggest to test this patch with patches from bug 17736 and bug 17737,
to place different kind of holds (biblio and item level, future and
past).
Then do a whole workflow to detect bug, view a record, delete record,
order, place a hold on an item which has been ordered, etc.
The hold's informations should always be the same without or without
these patches.
Tested both patches together, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Resolve warning from members/summary-print.pl:
"my" variable $itemtype masks earlier declaration in same scope
Test if find returns a Koha object in GetDescription.
Test if find returns a Koha object too in shelves.pl. While testing, I had
a crash on a biblioitem with itemtype NULL (bad record, but these things
tend to happen somehow.)
Can't call method "imageurl" on an undefined value at virtualshelves/shelves.pl line 253.
Same for opac/opac-shelves.pl.
Note: Did not add tests everywhere but generally, I have the impression that
we do not sufficiently test on the results of Koha::Object->find. Mostly we
just assume that it will find a record. Several reports include fixes to
resolve that wrong assumption.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
The C4::Koha::getitemtypeinfo subroutine did the almost same job as
GetItemTypes. On top of that it returned the imageurl value processed by
C4::Koha::getitemtypeimagelocation.
This value is only used from the 2 [opac-]shelves.pl scripts. Then it's
better not retrieve it only when we need it.
Test plan:
Play with the different scripts touched by this patch and focus on item
types. The same description as prior to this patch must be displayed.
Note that sometimes it is not the translated description which is
displayed, but that should be fixed on another bug report. Indeed we do
not expect this patch to change any behaviors.
Signed-off-by: Lari Taskula <lari.taskula@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
This patch updates the existing occurrences of ->find called in a list
context.
There are certainly others that are not easy to catch with git grep.
Test plan:
Confirm that the 4 modified scripts still works as expected.
We need this one ASAP in master to make sure we will not get other
side-effects of this kind and to catch possible uncaught occurrences
before the release.
Tested scripts changed by this patch, they work as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Once again, after bug 16154 and bug 16259 we need to remove more
occurrence of CGi->param called in list context.
Refer to bug 15809 for more information.
Test plan:
Make sure you do not see the error on the modified scripts.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
See bug 18552. When we resolved the housebound_role bug, the hash got
filled correctly again. And this revealed that the (second) call to
Koha::Patrons->find was not appropriate. It can be removed, as Jonathan
explained on the report.
Note: Commit 95429af685 added this call, but
it was hidden until the template variable hash got fixed.
Test plan:
Restart Plack and go to patron details again.
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>
Like:
Problem = a value of AutoResumeSuspendedHolds has been passed to param without key at /usr/share/koha/masterclone/C4/Templates.pm line 137.
Problem = a value of relatives_borrowernumbers has been passed to param without key at /usr/share/koha/masterclone/C4/Templates.pm line 137.
Problem is functions returning undef in list context (in this case
housebound_role).
No need to call Patrons::find a second time.
Note: The call of GetDebarments in the first patch suffered from this too.
It is in a fine place now too. But strictly speaking, should not have been
moved.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1) Go to a borrowers details page and create a manual restriction
2) Notice the restriction shows at the top of the page but the
restriction tab says the member is currently unrestricted
3) Apply patch and refresh page
4) Restrictions tab should now correctly show debarments and correct
number is shown
5) Confirming deleting and adding restrictions still works as expected
Sponsored-by: Catalyst IT
Followed test plan, works as expected
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
typo responsability
typo defautl in authorities.pref
typo reveived in t/db_dependent/Acquisition.t
typo ;; in advance_notices.pl
typo Stopping in restart_indexer (koha-indexer)
typo instutitional in moremember.pl
typo Corretly (Biblio.t)
typo periodicy in help serials
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
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>
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>
- minor changes on address format
- corrected member-password so that steetnumber is given to the template
Signed-off-by: Aleisha Amohia <aleishaamohia@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>
This patch updates the existing occurrences of ->find called in a list
context.
There are certainly others that are not easy to catch with git grep.
Test plan:
Confirm that the 4 modified scripts still works as expected.
We need this one ASAP in master to make sure we will not get other
side-effects of this kind and to catch possible uncaught occurrences
before the release.
Tested scripts changed by this patch, they work 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>
If they can have guarantors and we shwo the button on one page I think
we should in fact show it on all.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
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: 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>
This patch removes the retrieval of the syspref borrowerRelationship
from the scripts and moves it to a check using the Template Toolkit
plugin
To test:
1 - Apply patch
2 - Ensure 'Add child' button displays appropriately on all member pages.
Tested 3 pateches together, works as expected.
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: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The way the export options are displayed at the bottom of the checkouts table
was not consistent.
Prior to this patch set, they are display if ExportRemoveFields or
ExportWithCsvProfile is set.
It does not make any sense, the user could want to export the checkouts in
iso2709 format without having to define a csv profile and fill the pref.
Moreover the behavior of this pref did not match its description: it's used as
a default CSV profile when exporting records from the export tools or the
command line.
This patch set adds a new pref ExportCircHistory and remove
ExportWithCsvProfile. The new pref is set if ExportWithCsvProfile or
ExportRemoveFields were set.
A new dropdown list with the CSV profile list will be displayed in the
export area, at the bottom of the checkouts table.
Note that now --csv_profile_id is mandatory for the export command line
(misc/export_records.pl) if the export format is csv.
Test plan:
0/ Do not execute the DB entry
1/ Clear both ExportWithCsvProfile and ExportRemoveFields prefs
2/ Execute the DB entry
3/ ExportCircHistory should not be set and the export options should not
be displayed at the bottom of the checkouts table.
4/ Remove the pref
DELETE FROM systempreferences WHERE variable='ExportCircHistory';
and reinsert the previous one, with a value:
INSERT INTO systempreferences (variable, value) VALUES
('ExportWithCsvProfile', 'something');
Execute the DB entry again
=> The now pref should be now set
5/ Export some checkouts using the CSV entry
6/ Note that the export tool and commandline script still work using the
csv format. You have to provide a --csv_profile_id option to make it
work.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The parameter change in Koha::Token should be applied to the calling
scripts.
Test plan:
Confirm that the different forms of the scripts modified by this patch
still work correctly.
Test the problematic behavior:
Open 2 tabs with in same user's session, go on the edit patron page
(memberentry.pl).
Log out and log in from the other tab.
Submit the form
=> Wrong CSRF token should be raised
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch changes the way changed attributes are displayed for the
staff user to make the decision to approve (or not) the changes.
Regards
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
As reported by Owen, the members-update.pl was showing every attributes
the patron has (display issue) instead of showing only those affected by
the changes.
This patch fixes this by filtering the patron's attributes by opac
editability.
It also fixes Koha::Patron::Modification->approve so it only clears the
attributes with the updating 'code' and leaves the others untouched.
As its been coded so far (until someone refactors it all) the
Koha::Patron::Modification object needs to contain all the attributes
for a specific code. And it comes from parsing the UI's input.
Tests for Koha::Patron::Modification->approve to come.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch adds proper extended attributes display and handling on the
patron modifications moderation page (members-update.pl).
It also adds changes checking to the opac-memberentry.pl page so it
only saves a modification request if there are changes (it only checked
regular fields and not the extended ones).
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.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: Dobrica Pavlinusic <dpavlin@rot13.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When patrons don't have date of birth (which is not required) patron
search results on moremember page produce internal server error since we
can't convert MySQL invalid date 0000-00-00 to datetime object and
call strfdate on it.
Additionally, since we assign dates to template variables and after
than assign whole $data hash to template, later assigment overrides
previous one, so we see birth date field even for patrons which don't
have one.
This patch fixes both of those problems.
Test:
1. edit patron and remove it's birth date
2. try to search for it, and verify server error
3. apply patch
4. repeat search for patron and verify that it works and doesn't
have enpty birth date field
Signed-off-by: Grace McKenzie <grace.mcky@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Test plan:
0) apply the patch
1) try to pay individual fee, with full amount and partial amount
it should work the same as before patch
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If an attacker can get an authenticated Koha user to visit their page
with the url below, privilege escalation is possible
The exploit can be simulated triggering
/cgi-bin/koha/members/member-flags.pl?member=42&newflags=1&flag=superlibrarian
Test plan:
Trigger the url above
=> Without this patch, 42 is now superlibrarian
=> With this patch, you will get the "Wrong CSRF token" error.
This vulnerability has been reported by MDSec.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
On previous bugs
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The GetMemberIssuesAndFines subroutine used to retrieve the issues,
overdues and fines for a given patron. Most of the time, only 1 or 2 of
these values were used.
This patch removes this subroutine and uses the new get_issues,
get_overdues and get_balance method from Koha::Patron and Koha::Account::Lines.
Test plan:
1/ Add overdues, issues and fines to different patrons
2/ On the checkout, checkin and patron search result and the patron
detail pages, these 3 informations, if displayed before this patch, must be
correctly displayed.
3/ Use the batch patron deletion tool and make sure that patrons with a
balance > 0 are not deleted
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
WriteOffFee is the last of the "payment" subroutines that need to be
merged into Koha::Account::pay ( as a writeoff is really just type of
payment ).
Test Plan:
1) Apply this patch
2) Verify the writeoff, and writeoff all buttons still work
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Currently the card number is generated when the user enters the patron creation form. This creates a problem of concurrency - when two or more simulataneous users are registering members, the error "card no. in use" can occur.
This change moves the card number generation to occur after the "Save" button is pressed.
Changes:
-C4/Members.pm:
Added code to fixup_cardnumber,If the cardnumber is blank and "autoMemberNum" ON.
-koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt:
Added code to display "leave blank for auto calc during registration" in cardnumber label in patron registration form only if "autoMemberNum" ON.
-members/memberentry.pl:
Added code to get weather or not "autoMemberNum" is on or off and removed fixup_cardnumber generation.
Test cases:
-If "autoMemberNum" ON:
->In blank case, must generate auto card number in simulataneous users.
->If user entered, check for unique card number.
-If "autoMemberNum" OFF:
Must work normal.
Followed test plan, works as expected.
Note: Syspref PorrowerMandatoryField must not include cardnumber, otherwise
you can not save. Maybe that should be mentioned in the comment for
syspref autoMemberNum.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Test Plan:
1) Apply this patch
2) prove t/db_dependent/Accounts.t
3) Test fine payment via the "Pay selected" button
Signed-off-by: Laura Slavin <lslavin@hmcpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Test Plan:
1) Apply this patch
2) prove t/db_dependent/Accounts.t
3) Test fine payment via the "Pay" button,
but make the payment for less then the full amount
Signed-off-by: Laura Slavin <lslavin@hmcpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This reverts commit b6d5748c00.
As this bug report no more uses the accounline_id parameter to identify
account lines to pay in Koha::Account->pay, it should revert this, to
use the new notation everywhere.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If the userid of the logged in user contains unicode characters, the token
will not be generated correctly and Koha will crash with:
Wide character in subroutine entry at /usr/share/perl5/Digest/HMAC.pm line 63.
Test plan:
- Edit a superlibrarian user and set his/her userid to '❤' or any other strings
with unicode characters.
- Login using this patron
- Search for patrons and click on a result.
=> Without this patch, you will get a software error (with "Wide
character in subroutine entry" in the logs).
=> With this patch, everything will go fine
You can also test the other files modified by this patch.
Signed-off-by: Karam Qubsi <karamqubsi@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
All the values different from the ones GetMember returned has been
managed outside of GetMemberDetails.
It looks safe to replace all the occurrences of GetMemberDetails with
GetMember.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Same as authflags, a flags key is set containing all the patron flags.
It is only used in a few places and it's better to call
C4::Members::patronflags when we need it.
Test plan:
Look at the diff and confirm that the change make sense
Use git grep to confirm we do not use the flags somewhere else.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
GetMemberDetails create a authflags key, but this key is only used from
2 different places.
One is a very simple script, which does not seem very usefull
C4/SIP/interactive_members_dump.pl. I propose to simply remove it.
The other one is the member-flags.pl script. What is done in this one is
a bit weird since we a doing twice the same query (it was not highlighted
before this patch). We will need to fix that later.
At the moment the goal it to remove the GetMemberDetails subroutine
without introducing any regressions (and so without adding big changes)
Test plan:
Select/unselect permissions for a patron, save and edit again.
The behavior of the permission checkboxes should be ok
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
As said in the previous commit, I considered SetAge as unnecessary and
removed it.
Test plan:
1/ Edit a patron using the different 'Edit' links
2/ Play with the patron category limited to age ranges, and date of
birth
3/ You should get the expected warning if the date of birth is inside
the patron category date range.
To finish:
prove t/Circulation/AgeRestrictionMarkers.t t/db_dependent/Reserves.t \
t/db_dependent/Koha/Patrons.t t/db_dependent/Members.t
should return green
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
We can solve the minor problem reported on 15906 now by using the
accountlines_id parameter of this report.
Test plan:
[1] Add two manual fines (say 20 and 30).
[2] Pay the second one in full, and check that the first one is not paid
first. So the 20 should remain and not the 30 with 20 outstanding.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Test plan:
1) Apply this patch
2) Make a payment in full using the "Pay" button
3) Note payment succeeds
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
From the pod of Digest::MD5:
"""
Since the MD5 algorithm is only defined for strings of bytes, it can not
be used on strings that contains chars with ordinal number above 255
(Unicode strings). The MD5 functions and methods will croak if you try
to feed them such input data.
What you can do is calculate the MD5 checksum of the UTF-8
representation of such strings.
"""
Test plan:
- Set a MySQL/MariaDB password with unicode characters:
UPDATE user SET password=PASSWORD('❤') WHERE USER='koha_kohadev';
FLUSH PRIVILEGES
- Update your $KOHA_CONF file
- Restart Memcached
- Hit the files modified by this patch
=> Without this patch, you will get a software error (with "Wide
character in subroutine entry" in the logs).
=> With this patch, everything will go fine
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Edit: removed debugging leftover
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
members/moremember.pl will set mobile number as smsalertnumber in template if
smsalertnumber is not defined. This will cause incorrect display for SMS number
in patron's Details-tab. This confusion between smsalertnumber and mobile is
already fixed in Bug 14683, but members/moremember.pl was not fixed yet.
This is a minor issue since it won't occur for manually added new patrons due to
fixes already pushed in Bug 14683, but in case patron's smsalertnumber is null
in database, this bug can be replicated:
To test:
1. Set EnhancedMessagingPreferences to "Allow" and make sure SMSSendDriver
has been set.
2. Add a new patron, give it a mobile/other phone number.
3. Run a SQL query:
update koha.borrowers set smsalertnumber=NULL where borrowernumber=XXX;
(replace XXX with your new patron's borrowernumber)
4. Go to patron's details tab and observe that SMS number shows the mobile/
other phone you provided earlier.
5. Apply patch.
6. Refresh patron's details tab.
7. Observe that smsalertnumber is now empty, as it should be.
Followed test plan, works as expected.
Signed-off-by: Marc <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Following patron modification partial editor had no age constraint
checking:
/cgi-bin/koha/members/memberentry.pl?op=modify&borrowernumber=3&step=3
Test plan:
1) Apply the patch
2) Open profile of a patron
3) Click Edit under "Library use": http://prntscr.com/d1ghim
4) Change category to an invalid one (eg. Adult instead of Kid)
5) Error saying "Patron's age is incorrect for their category." should
be displayed.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Lucio Moraes <lmoraes@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This bug has been highlighted by bug 15407.
The date limit check on the category code did not work on step 1. But
after bug 15407 the script crashes with
Can't call method "dateofbirthrequired" on an undefined value at
/home/vagrant/kohaclone/members/memberentry.pl line 311.
Test plan:
- Edit "step 1" information of a patron (first 'Edit' on a patron detail
page).
- Save
=> Without this patch it BOOMs
=> With this patch, the info should be correctly saved
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Prevent internal software error when searching patron with invalid birth date
To reproduce:
- Go to Home > Patron
- Expand patron search (click on + at the left of the search button)
- In drop down 'Search fields', select 'Date of birth'
- Enter a valid date (e.g. 11.02.1995 if syspref 'dateformat' is set to dmydot)
Result: Search works OK
- Enter an invalid date, e.g. 11.02 or abcd...
Result: Internal server error
- Do a patron search with many results
- Use filter on results screen, select 'Date of birth' as search field and
enter an invalid date to search (e.g. 'a')
Result: Endless message 'Processing'
To test:
- Apply patch
- Repeat steps above
- In both cases, you should get "No results"
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Lucio Moraes <lmoraes@catalyst.net.nz>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
* Koha/Patron.pm (housebound_role): New method.
* koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember.tt: Add
section for HouseboundRole information
* members/moremember.pl: Pass HouseboundRole info to template.
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
I think it's better to prefix the subroutine names used to search with
'search_'.
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
* members/housebound.pl: Provide full patron hash keys, extended patron
attributes & picture to template.
* koha-tmpl/intranet-tmpl/prog/en/modules/members/housebound.tt:
Refactor to use new information.
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
* members/housebound.pl: Force `borrowernumber` to scalar context.
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
* koha-tmpl/intranet-tmpl/prog/en/modules/members/housebound.tt: Use
".datepicker" class for date input, use `$KohaDates` to filter our iso
dates.
* members/housebound.pl: Use DateTime and Koha::DateUtils to parse
incoming date to ISO format.
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
* members/housebound.pl: Refactor & store messages for encountered
errors.
* koha-tmpl/intranet-tmpl/prog/en/modules/members/housebound.tt: Show
messages.
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
New module to handle management of circulation to Housebound readers.
- Ability to create housebound profiles & scheduled visits for patrons.
- Ability to record users as Deliverers or Choosers (or both), using
extended patron attributes.
- Ability to link choosers and deliverers to individual delivery runs.
- 'Delivery Frequencies' are customizable through authorised
values ('HSBND_FREQ').
* koha-tmpl/intranet-tmpl/prog/en/includes/circ-menu.inc: add
Housebound menu if appropriate.
* Koha/Patron.pm (housebound_profile): New method.
* Koha/Patrons.pm (housebound_choosers, housebound_deliverers): New
methods.
* Koha/Patron/HouseboundProfile.pm: New File.
* Koha/Patron/HouseboundProfiles.pm: New File.
* Koha/Patron/HouseboundVisits.pm: New File.
* Koha/Patron/HouseboundVisit.pm: New File.
* koha-tmpl/intranet-tmpl/prog/en/modules/members/housebound.tt: New file.
* members/housebound.pl: New file.
* installer/data/mysql/kohastructure.sql: Add housebound_* tables.
* installer/data/mysql/sysprefs.sql: Add HouseboundModule syspref.
* koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/circulation.pref:
Add HouseboundModule syspref.
* installer/data/mysql/atomicupdate/housebound_tables.sql: New file.
* t/db_dependent/Patron/Borrower_Housebound.t: New file.
* t/db_dependent/Patron/Borrower_HouseboundProfiles.t: New file.
* t/db_dependent/Patron/Borrower_HouseboundVisits.t: New file.
Test plan:
- Apply patch.
- Run atomic update script.
- Run Unit Tests (t/db_dependent/Patron/Housebound*)
- Optionally, add additional authorised values to 'HSBND_FREQ'.
- Switch on 'HouseboundModule' syspref.
- Ensure 'ExtendedPatronAttributes syspref is on.
- On patron pages, when editing, add some to the Housebound deliverer
and chooser groups.
- On a patron page, the Housebound menu should now be present.
- create housebound profile
+ ensure Frequency values seem pulled from 'HSBND_FREQ'.
- create 'housebound visits' (deliveries)
+ ensure chooser/deliverer lists are populated with patrons that
have the Chooser or Deliverer Attribute type.
- edit visits.
- delete visits.
- Switch off 'HouseboundModule'
- the Housebound menu should disappear
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Bug 5670: [Followup] Rename test files.
* t/db_dependent/Patron/Borrower_Housebound.t: Rename to
t/db_dependent/Patron/Housebound.t.
* t/db_dependent/Patron/Borrower_HouseboundProfiles.t: Rename to
t/db_dependent/Patron/HouseboundProfiles.t.
* t/db_dependent/Patron/Borrower_HouseboundVisits.t: Rename to
t/db_dependent/Patron/HouseboundVisits.t.
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Bug 5670: [QA Followup] Fix category_type ref.
* koha-tmpl/intranet-tmpl/prog/en/modules/members/housebound.tt: Replace
references to `category_type` with `categorycode`.
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This job should be done each time patron data are deleted. It's better
to do it just before deleting the patron than assuming the caller did
the job by itself.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch moves the C4::Members::DelMember subroutine to the
Koha::Patron module.
The delete method must be overwritten to permit handling of patron's
holds.
Test plan:
(With the 2 patches applied)
1/ Create a patron with holds and owner of lists
2/ Delete patrons using the web interface:
- More > Delete on a patron page
- Batch patron deletion tools
3/ and the cronjob script
- perl misc/cronjobs/delete_patrons.pl -c [more options]
The patron should have been moved to the deletedborrowers table, his/her
holds and lists should have been deleted.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch removes the C4::Members::MoveMemberToDeleted subroutine in
order to replace it with the Koha::Patron->move_to_deleted method.
Next after this change, we will move C4::Members::HandleDelBorrower and
C4::Members::DelMember to the same module to simplify the code in
members/deletemem.pl and misc/cronjobs/delete_patrons.pl
Test plan:
1/ Delete a patron from the staff interface and make sure (s)he has been moved to
the deletedborrowers table.
2/ Use the "Batch patron deletion" tool (tools/cleanborrowers.pl) to
remove patron. Make sure the "Permanently delete these patrons" and "Move
these patrons to the trash" options work as before
3/ Same as previously but using the cronjob
misc/cronjobs/delete_patrons.pl.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Tested the delete_patrons.pl script and cleanborrowers.pl too.
Tests (are relevant and) pass and the qa scripts are happy too :-D
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The subroutine C4::Koha::GetAuthorisedValueByCode returned the
description (staff or opac) for a given authorised value.
Note that we may need a unique key to ->find instead of ->search.
Test plan:
- Checkin an item that cannot be checked in because it's lost, the
message should display the AV description
- Generate a letter with borrowers.streettype equals an ROADTYPE AV, the
description should be displayed.
- Edit a patron attribute type, the AV dropdown list should be
displayed
- Create the PA_CLASS AV category (see bug 7154) and make sure it
behaves as before when editing a patron
- The checkout list should display descriptions for LOC, LOST and
DAMAGED
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When displaying Fines > Account tab for a patron, you can see on screen a Note column that is missing if you click on Print
Test plan :
* Find a patron with accountlines or add them manually (Create manual invoice/credit).
* Be sure some of them got a Note
* Clik on Print fior those lines
Without patch, the printed receipt does not show the Note column
with the patch, the printed receipt shows a Note column and Note content is correctly printed for accountline with a note.
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 14566 added the permission "borrowers" on patronimage.pl.
This perm is too restrictive because circulation pages also uses this page.
I propose to simply use "catalogue" perm.
Test plan
- Set an image to borrower xx
- Create a user with only catalogue permission
- Log with this user
- Go to page (replace xx by borrower number) : /cgi-bin/koha/members/patronimage.pl?borrowernumber=xx
=> Without patch you get the page saying you do not have the permission
=> With patch you get the image
- Log out and retest the page patronimage.pl
=> You get 403 error
Signed-off-by: remy <remy.gonzalves@iepg.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This patch adds escaping to url params in mambers/pay.pl
To test:
- Apply patch
- Go to Home > Patrons > Manual invoice and create an invoice with a
description containing a #
- Go to tab "Pay fines"
- Write off the fine
Expected result: Fine is written off and does no longer display in pay tab.
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This patch fixes a Internal Server Error while deleting patrons.
To reproduce:
- Go to a patron's detail page
- Toolbar : More : Delete
- Confirm "Are you sure you want to delete..."
Result: Internal Server Error
Plack error log:
exited nonzero: 1 at /home/marc/koha/members/deletemem.pl
Note: Patron is deleted
Additional tests: Try to delete yourself, to delete a staff member
without having superlibrarian permission etc.
To test:
- Apply patch
- Re-start plack
- Try to reproduce steps above (with other patron)
Expected result:
No Internal Server Error, Redirect to Home > Patrons
Amended to include all occurences of 'exit 1'
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Good catch Marc
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
To reproduce:
- Go to Home > Administration > Patron categories
- Make sure that you have only one category for a category type.
Examples: Only one category "Staff" for category type "Staff" or
Only one category "Library" for category type "Org."
- Edit a patron or create a new patron
- Verify that categories of examples above do not show up in category drop down
- Go back to Home > Administration > Patron categories and add categories to
both category types
- Edit or create a new patron. Veryfy that categories show up in dropdown.
To test:
- Apply patch
- Make sure you have a category type with only one category assigned
(e.g. category taype Staff with category Staff)
- Edit a patron or create a new patron. Verify that the category
shows up in categroy drop down.
- Additional test: Verify that template param 'catcode' from removed line
is not used in template memberentrygen.tt
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Test Plan:
1) Apply this patch
2) Pay a fine via the "Pay amount" button
3) Payment should succeed.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Given that the issue is trying to call a method on something that isn't
an object, because the category code doesn't exist, then why is it
even trying to change the expiry date? A simple postfix if fixes it.
Applied counter-patch by M. Tompsett. All three patron 'Edit' links
mentioned in previous patch's test plan work fine.
Signed-off-by: Andreas Roussos <arouss1980@gmail.com>
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If an attacker can get an authenticated Koha user to visit their page
with the
url below, they can change or delete patrons' images
/tools/picture-upload.pl?op=Delete&borrowernumber=42
Test plan:
1/ Hit /tools/picture-upload.pl?op=Delete&borrowernumber=42
And confirm that you get a "Wrong CSRF token" error
2/ Go on the patron detail page with a patron's image
3/ Click on the Delete link (note the csrf_token param)
4/ The image will be deleted and you are redirected to the patron detail
page.
Regression tests:
Upload an image from the patron detail page and from the "upload patron
images" tool.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The patron details page always show the logged in library as the
patron's home library instead of the true home library. This bug is
particular to moremember.pl and does not affect other patron pages.
Test Plan:
1) Find a patron with a home library other than the logged in library
2) Note the patron home library as shown on moremember.pl matches
the logged in library and not the patron's true home library
3) Apply this patch
4) Reload moremember.pl, the correct home library should display!
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This subroutine was only used in one script and its job is the same as
GetAuthorisedValueByCode.
It's better to use the AuthorisedValues TT plugin to retrieve AV
descriptions.
Test plan:
Edit a patron with sort1 and/or sort2 defined.
On the patron details page (members/moremember.pl) you should see the
sort1 and/or sort2 info displayed.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch moves the code from C4::Members::ExtendMemberSubscriptionTo
to Koha::Patron->extend_subscription.
The expected behavior is:
When a new patron is created, the enrolment period defined for the
patron category is used unless an enrolment period date is defined. In
that case, this date is used.
When an account is renewed, the pref BorrowerRenewalPeriodBase is used to
determine if the subscription is renewed from today or from the day when his/her
account has expired.
Test plan:
Confirm that the behavior is correct before this patch and that it's
still the same after this patchset applied.
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch moves the code from C4::Members::GetExpiryDate to
Koha::Patron::Categories.
Nothing much exiting, please follow test plan in next patches.
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This is the fourth and last patch set to remove C4::Branch.
The real purpose of this patch is to standardise and refactor some code
which is related to the libraries selection/display.
Its unconfessed purpose is to remove the C4::Branch package.
Before this patch set, only 6 subroutines still existed in the C4::Branch
package:
- GetBranchName
- GetBranchesLoop
- mybranch
- onlymine
- GetBranches
- GetBranch
GetBranchName basically returns the branchname for a given branchcode.
The branchname is only used for a display purpose and we don't need to
retrieve it in package or pl scripts (unless for a few exceptions).
We have a `Branches` template plugin with a `GetName` method which does
exactly this job.
To achieve this removal, we will use this template plugin and delete the
GetBranchName from pl and pm files.
The `Branches.all()` will now select the library of the logged in user
if no `selected` parameter has been passed.
This new behavior could cause regressions, for instance there are some
places where we do not want an option preselected (batch item
modification for instance), keep that in mind when testing.
GetBranchesLoop took 3 parameters: $branch and $onlymine.
The first one was used to set a "selected" flag, for a display purpose:
select an option in the libraries dropdown lists.
The second one was useless: If not passed or set to 0, the
`C4::Branch::onlymine` subroutine was called.
This onlymine flag was use to know if the logged in user was able to see
other libraries infos.
A patron can see the infos from other libraries if IndependentBranches
is not set OR if he has the superlibrarian permission.
Prior to this patch set, the "onlymine test" was done on different
places (neworderempty.pl, additem.pl, holidays.pl, etc.), including the
Branches TT plugin. In this patch set, this test is only done on one
place (C4::Context::only_my_library, code moved from
C4::Branch::onlymine).
To accomplish the same job as this subroutine, we just need to call the
`Branches.all()` method from the `Branches` TT plugin. It already
accepts a `selected` parameter to set a flag on the option to select.
To avoid the repetitive
[% IF selected %]<option selected="selected">[% ELSE %]<option>[% END %]
pattern, a new `html_helpers` TT include file has been created, it
defines an `options_for_libraries` block, which takes a `selected`
parameter. We could imagine to use this include file for other
selects.
The 'mybranch` and `onlymine` subroutines of the C4::Branch package have
been moved to C4::Context. onlymine has been renamed with
only_my_library. There are only 4 occurrences of it, against 11 before
this patch set.
There 2 subroutines are Context-centric and it makes sense to put them
in `C4::Context` (at least it's the least worst place!)
GetBranches is the tricky part of this patch set: It retrieves all the
libraries, independently of the value of IndependentBranches.
To keep the same way as the existing calls of `Branches.all()`, I have
added a `unfiltered` parameter. If set, the `Branches.all()` will call
a usual Koha::Libraries->search method, otherwise
Koha::Libraries->search_filtered will be called. This new method will
check if the logged in user is allowed to see other libraries or only
its library.
Note that this `GetBranches` subroutine also created a `category` key:
it allowed to get the list of groups (of libraries) where this library
existed. Thanks to a previous patch set (bug 15295), this value was
not used anymore (I may have missed something!).
Note that the only use of `GetBranch` was buggy (see bug 15746).
Test plan (for the whole patch set):
The best way to test this whole patch set is to test with 2 instances: 1
with the patch set applied, 1 using master, to be sure there is no
regression.
It would be good to test the same with `IndependentBranches` and the
without `IndependentBranches`.
No difference should be found.
The tester must focus on the library dropdowns on as many forms as
possible.
You will notice changes in the order of the options: the libraries will
now be ordered by branchname (instead of branchcode in some places).
A special attention will be given to the following page:
- acqui/neworderempty.pl
- catalogue/search.pl
- members/members-home.pl (header?)
- opac/opac-topissues.pl
- tools/holidays.pl
- admin/branch_transfer_limits.pl
- admin/item_circulation_alerts.pl
- rotating_collections/transferCollection.pl
- suggestion/suggestion.pl
- tools/export.pl
Notes for QA:
- There are 2 FIXMEs in the patch set, I have kept the existing behavior,
but I am not sure it's the good one. Feel free to open a bug report and
I will fill a patch if you think it's not correct. Otherwise, remove the
FIXME lines in a follow-up patch.
- The whole patch set is huge and makes a lot of changes.
But it finally will tremendously reduce the number of lines:
716 insertions for 1910 deletions
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This unnecessary complicated subroutine returned an arrayref and an
hashref of the patron categories available for the logged in user, for a given
category_type, ordered by categorycode.
This can now be done with the search_limited method.
Test plan:
- Same prerequisite as before
For the following pages, you should not see patron categories limited to other
libraries. They should be ordered as before this patch, by categorycode.
- Add/edit a patron, change his/her patron category value.
- On the 3 following reports:
reports/bor_issues_top.pl
reports/borrowers_out.pl
reports/cat_issues_top.pl
The display for these 3 reports are different than the 2 from the first
patch (borrowers_stats.pl issues_avg_stats.pl): they are ordered by
categorycode and the ones limited to other libraries are not displayed
(should certainly be fixed).
Note that the big part of this patch has already been tested before
(update child related: CATCODE_MULTI).
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The purpose of C4::Members::GetBorrowercategory was to return the patron
category for a given categorycode. This can be done easily with the
Koha::Patron::Categories->find method.
Test plan:
- Same prerequisite as before
- Edit a guarantor and confirm the information will be updated for his/her
guarantee(s).
- Update a child to adult patron (Note: Should not we hide the patron
categories limited to others libraries? If yes, it must be done on another
bug report).
There is a special behavior if there is only 1 adult category, the
user does not need to select a category. So the same as before with
only 1 adult patron category.
- Import a patron with a category_code which does not exist. You should
be warned.
- Modify some patron using the batch patron modification tool. The
patron category descriptions should correctly be displayed.
Note that the overduerules page has already been tested in a previous
patch.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The C4::Category module contained only 1 method to return the patron
categories available for the logged in user.
The new method Koha::Patron::Categories->search_limited does exactly the
same thing (see tests) and must be used in place of it.
Test plan:
- Same prerequisite as before
For the following pages, you should not see patron categories limited to
other libraries.
- On the 'Item circulation alerts' admin page
(admin/item_circulation_alerts.pl), modify the settings for check-in
and checkout (NOTE: Should not we display all patron categories on
this page? If yes, it must be done in another bug report to ease
backporting it).
- Search for patrons in the admin (budget) and acquisition (order) module.
- On the patron home page (search form in the header)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
$borrowernumber is used in build_issue_data but not correctly defined
(Variable "$borrowernumber" is not available)
That may cause wrong charge displayed in the summary slip.
Test plan:
- Set rental charge for an item type
- Define a rental discount for that item type in the circ rules
- check in an item matching this rule
Without this patch the charge displayed in the summary slip won't be
calculated with the discount
With this patch applied, the warning in the logs will no longer appear
and the values will be correctly calculated.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The changes from opac-memberentry do not reach the table, since the
Patron::Modifications object does not work well.
Test Plan:
1) Apply this patch
2) Create some patron modification requests
3) Ensure you can approve and deny modifications
4) Ensure patron self registration works
Signed-off-by: Bob Birchall <bob@calyx.net.au>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This alternative patch moves logic and formatting to the template file.
To test:
* without patch
1/ find a patron with no lines in accountlines table : print summary shows no "account fines and payments" => OK
2/ find a patron with some lines in accountlines table and the total amount > 0 : print summary shows a table "account fines and payments" with fines to recover => OK
3/ find a patron with some lines in accountlines table but the total amount = 0 : print summary shows a table "account fines and payments" with nothing in it => NOK
* with the patch, same cases as before :
1/ same as without patch
2/ same as without patch
3/ print summary does not show "account fines and payments"
- Additionally, verify that formatting follows syspref 'CurrencyFormat'
- Verify that amount column is right-aligned
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Adds one exit statement, and some whitespace.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Verified deleting a patron again.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If an attacker can get an authenticated Koha user to visit their page
with the url below, they can delete patrons details.
/members/deletemem.pl?member=42
Test plan:
0/ Do not apply any patches
1/ Adapt and hit the url above
=> The patron will be deleted without confirmation
2/ Apply first patch
3/ Hit the url
=> you will get a confirmation page
4/ Hit /members/deletemem.pl?member=42&delete_confirmed=1
=> The patron will be deleted without confirmation
5/ Apply the second patch (this one)
6/ Hit /members/deletemem.pl?member=42&delete_confirmed=1
=> you will get a crash "Wrong CSRF token" (no need to stylish)
7/ Delete a patron from the detail page and confirm the deletion
=> you will be redirected to the patron module home page and the patron
has been deleted
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
It won't hurt to have a confirmation page when deleting a patron.
Moreover it's the more easy way to protect against CSRF attacks :)
Test plan:
Make sure you get a confirmation page when deleting a patron
Confirm that approving or denying the confirmation work as expected
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The patron category description is not passed to the template in
paycollect.pl
Note: The Categories TT plugin should be used here...
Test plan:
Go on paycollect.pl and confirm that the patron category description is
now displayed in the sidebar.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Brendon Ford <brendon.ford@manhattan.edu>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If an attacker can get an authenticated Koha user to visit their page with the
url below, they can change patrons' passwords
/members/member-password.pl?member=42&newpassword=hacked&newpassword2=hacked
Test plan:
Trigger
/members/member-password.pl?member=42&newpassword=hacked&newpassword2=hacked
=> Without this patch, the password will be updated
=> With this patch applied you will get a crash "Wrong CSRF token" (no
need to stylish)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If we do not fill a new userid, we should keep the old one.
Script member-password should pass that to Koha::Patron.
Otherwise things go wrong.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Without this patch, you could effectively disable a login.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
If an attacker can get an authenticated Koha user to visit their page
with the url below, they can change patrons' passwords or other
patrons'details
members/memberentry.pl?op=save&destination=circ&borrowernumber=3435&password=ZZZ&password2=ZZZ&nodouble=1
Test plan:
Trigger
members/memberentry.pl?op=save&destination=circ&borrowernumber=42&password=ZZZ&password2=ZZZ&nodouble=1
=> Without this patch, the password will be updated
=> With this patch applied you will get a crash "Wrong CSRF token" (no
need to stylish)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Amended: removed the commented use Digest::MD5-line.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This subroutine just reads the content of a pref, split it, add an
empty string and returns.
It is not really useful and the code in the script (memberentry.pl) uses
the only occurrence of CGI::popup_menu
Let's remove it and build the dropdown list in the template.
Test plan:
1/ Empty BorrowersTitles, edit a patron and confirm that the "Salutation"
does not appear
2/ Fill BorrowersTitles with "Mr|Mrs|Miss|Ms", edit a patron and confirm
that the "Salutation" dropdown list is correctly filled.
The default option should be selected if you are editing a patron with a
title defined.
This should also be tested at the OPAC.
Followed test pan, works as expected in Staff and OPAC
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To reproduce:
- Go to staff client Home > Patron
- New patron
- Choose a category and fill form, submit
Result: Form reloads, patron data are not saved.
To test:
- Apply patch
- Repeat steps above
- Verify that patron data are saved and the new patron's
detail page displays
- Try to enter a duplicate patron (e.g. same surname, firstname
and birthday as above)
- Verify that a duplicate message appears
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
C4::Members::checkuniquemember was not really nicely written, was only
used once and was not covered by tests.
I think it does not make sense to keep such complexity and have this
code in the subroutine/method.
Looking at this patch it seems that what this subroutine did can be done
easily in the pl script in few lines.
Test plan:
1/ Create 2 organisations with the same "surname": you should get a
warning.
2/ Create 2 patrons (non-organisation) with the same
surname/firstname/date of birth, you should get a warning
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch moves the code from C4::Members::changepassword to
Koha::Patron->update_password
Test plan:
Change your password at the OPAC and the staff interface
This should work as before
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
I rebased this on top of 16849 because they were conflicting.
Tests pass, code looks good (as usual) and I checked both OPAC
and staff password change work as expected.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
In order to move IsMemberBlocked to Koha::Patron it makes sense to move
the code from Koha::Patron::Debarments::IsDebarred to
Koha::Patron->is_debarred.
Test plan:
1/ Add a restriction to a patron
2/ make sure he is not able to checkout items any more
3/ Make sure he cannot get a discharge
4/ Put a hold and make sure you get "Patron has restrictions"
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch adds a new system preference:
PatronQuickAddFields
When either this pref or BorrowerMandatoryField is populated this will add a new dropdown to the bew patron toolbar.
When a category is chosen from this dropdown the fields in PatronQuickAddFields and BorrowerMandatoryField will be displayed.
There will be a button allowing a user to switch from the quickadd to the full form and fields will be copied between the forms when toggling.
The Quick add will only be displayed on add of a new patron, future edits should display the full form.
Test plan:
1 - Apply patch
2 - run updatedatabase.pl
3 - Add a new patron and ensure nothing has changed
4 - Populate either PatronQuickAddFields or BorrowerMandatory fields
and note the new button for adding a patron
5 - Click the Quick add and choose a type
6 - Only required or quick add fields should be displayed
7 - Verify toggling forms copies information
8 - Ensure you cannot save patron without filling required fields
(quick add fields should be optional)
9 - Ensure you can save patron with fields filled out
10 - Ensure that a duplicate patron brings up the duplicate/add new
buttons with full form displayed
11 - Verify that subsequent edits use only full form
12 - Verify that data on form submitted is the data saved to patron
13 - Test with various values in both MandatoryBorrowerFields and PatronQuickAddFields
Sponsored by: VOKAL (Vermont Organization of Koha Automated Libraries)
Followed test plan, works as expected.
Re-tested together with followup, works as expected (2016-06-02)
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>
This patch moves all the code into an include which can be accessed from the 'Add a new message' link or the patron toolbar.
EDIT: Ensuring modal opens on all pages
EDIT2: Once the form has been submitted the page will redirect to where you submitted the form from.
EDIT3: Fixing indentation of member-add-message.inc
Ensuring messages save on every page
Fill branch
Ensure predefined notes appear
Form redirects to where it was submitted from, or just the circulation page.
EDIT4: Removing the new include file and moving it all into the modal in the toolbar
EDIT5: Removing swp file and unnecessary code duplication by utilising plugins
EDIT6: Batch checkout fixes
EDIT7: Ensure you do not get JS error from Comment 24 (Batch checkout syspref must be turned on)
To test:
1) Go to a patron circ page (circ/circulation.pl?borrowernumber=X)
2) Click 'Add a new message' under Messages
3) Confirm this brings up the modal to add a message. Confirm clicking Save saves your message. If it is an OPAC message (for the user), confirm it shows as expected on the OPAC.
4) Click Cancel. Confirm this closes the modal.
5) Click 'Add message' button in toolbar. Complete steps 3 and 4.
6) Confirm the modal opens from all other pages with the members toolbar. Confirm predefined notes shows.
circ/circulation.pl
members/moremember.pl
members/routing-lists.pl
members/statistics.pl
members/boraccount.pl
members/pay.pl
members/maninvoice.pl
members/mancredit.pl
members/readingrec.pl
members/notices.pl
members/member-flags.pl
members/member-password.pl
members/paycollect.pl
members/files.pl
turn on BatchCheckouts syspref and put in appropriate patron category
circ/circulation.pl?borrowernumber=X&batch=1
7) Confirm that the page redirects to where you submitted the form from once you have submitted it.
8) Go to Check Out tab and confirm your message saved (or OPAC, wherever you saved it)
Sponsored-by: Catalyst IT
Followed test plan, works as expected. (Re-tested for comment #24)
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>
When paying a fine, the description is built out of the borrower's type and title, instead of the actual fine's description.
STEPS:
1) in the staff, go to a user with a fine to pay.
a) if none, go to a user and Fines>>"Create manual invoice" with a distinctive description.
2) In Fines>>Pay fines, click the "Pay" button on the line of the fine.
3) This will take you a "Pay an individual fine" screen, where the description will look like "Staff Mrs", for the category and title of the borrower.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
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>
EDIT: Fix for OPAC side
EDIT: Comment 10
EDIT: Merge conflicts
To test:
1) Ensure syspref useDischarge is disabled
2) Go to /cgi-bin/koha/members/discharge.pl?borrowernumber=X&discharge=1
3) Validate that you are still able to generate a discharge slip for this patron
4) Apply patch and refresh page
5) Confirm that you are redirected to the circulation.pl page for the user and that an error message is there.
OPAC SIDE
6) Go to the OPAC
7) Go to /cgi-bin/koha/opac-discharge.pl
8) Confirm you get a message saying discharges are disabled
9) Go to /cgi-bin/koha/opac-discharge.pl?op=request
10) Confirm you see same message
Sponsored-by: Catalyst IT
Followed test plan, works as expected (both staff client and OPAC).
Re-tested, works OK.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
The root of this issue is old code in circulation.pl that is no longer
needed and leaves the affected scripts open to future regressions.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Heather Braum <hbraum@nekls.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Some librarians have requested that the same warning on the check out
page be placed on the patron details page if a patron's fines exceed the
system preference noissuescharge.
Test Plan:
1) Apply this patch
2) Find or create a patron who's fines exceed noissuescharge
3) Browse to that patron's details ( moremember.pl )
4) You should see a warning near the top of the page with links to the
patron's account page and the pay fines page
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Patch ammended post sign-off
Signed-off-by: Sally Healey <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch replaces the occurrences of
my @foo = $cgi->param('foo');
with
my @foo = $cgi->multi_param('foo');
perl -p -i -e
's/^(\s*my\s*@\w+\s*=\s*)\$(cgi|input|query)\->param\(/$1\$$2\->multi_param\(/xms'
**/*.pl
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
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>
The default patron search types has changed from 'contain' to
start_with. Users consider it as a bug.
This patch revert the previous changes to default on 'contain'.
Test plan:
Search for patrons in different places (guarantor, checkout, patron
module, acquisition module, etc.) and confirm that the default is always
'contain'
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
From C4::Koha::GetAuthorisedValues
# TODO: the "selected" feature should be replaced by a utility function
# somewhere else, it doesn't belong in here. For starters it makes
# caching much more complicated. Or just let the UI logic handle it, it's
# what it's for.
Indeed, it's not a job for a subroutine, the template should take care of that.
Note that a perf gain could be won with this patch \o/
Test plan:
- Edit an itemtype and check the value of the "Search category" dropdown list
- Edit a patron attribute type and check the value of the "Class" dropdown list
- Detail for a catalogue record, the Status column should be correctly
populated if items are damaged and/or lost
- Item details for a catalogue record, the lost, damaged and withdrawn
value should be correctly displayed
- Edit a patron, the "street type" should be correctly selected
- Create a patron attribute type linked to an authorised value list.
- Edit a patron, set a value for this attribute, edit it again. The
correct value should be selected.
- Search for subscriptions. The 'Location' dropdown list should behave
correctly (select the entry you have choosen before, etc.)
- Edit a subscription, the location dropdown list should select the
correct value.
- Edit and view a suggestion with a 'reason for suggestion' set (you
should have at least 1 OPAC_SUG AV defined)
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: Brendan Gallagher brendan@bywatersolutions.com
To test:
1 - Add guarantor data to patron account by typing it in but do not 'Set to patron'
2 - Note it is not displayed on patron details
3 - Apply patch
4 - Note the info is displayed
5 - Test that linked guarantors show as expected
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Amended-patch: Correct some indents/spaces
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
The patron attributes displayed on editing a patron are not displayed if
limited to another library.
C4::Members::Attributes::SetBorrowerAttributes will now only delete attributes
the librarian is editing.
SetBorrowerAttributes takes a new $no_branch_limit parameter. If set,
the branch limitations have not effect and all attributes are deleted
(same behavior as before this patch).
Test plan:
1/ Create 2 patron attributes, without branch limitations.
2/ Edit a patron and set a value for these attributes
3/ Limit a patron attributes to a library (one you are not logged in
with).
4/ Edit again the patron.
=> You should not see the limited attributes
5/ Edit the patron attributes and remove the branch limitation
=> Without this patch, it has been removed from the database and is not
displayed anymore.
=> With this patch, you should see it.
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
$borrower, $borrowernumber and $template and not visible in the
subroutine.
Using $b_ref and passing $template fixes the issue.
Test plan:
Under plack, use the pay selected button.
On the paycollect page, you should see the image of the patron
It certainly fixes some other bugs.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Note:
QA question: Does the Koha::Patron->siblings method should return undef
if there is no guarantor?
It would avoid the weird != undef, = $borrowernumber conditions.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
2 subroutines of C4::Members deal with guarantor/guarantees:
GetGuarantees and GetMemberRelatives.
Since we already have a Koha::Patron->guarantor method, it makes sense
to move these 2 subroutines to this module.
This first patch deals with GetGuarantees.
Test plan for the entire patch set:
1/ Create 5 patrons A (adult), B (child), C (child), D (child), E
(child), F (adult)
2/ Add relation between them: A is father of B, C and D.
E does not have a guarantor
F does not have guarantees
3/ Check some items out for all of these patrons
4/ On the "Check out" and "Details" tabs, you should not see any
differences with these patch applied : The "Relatives' checkouts" tabs
should list all of the guarantor/guarantee/siblings checkouts
Note:
$template->param('C' => 1);
I have not found any reference of this 'C' in the template.
It seems it's an old c/p from members/memberentrygen.tt
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
To retrieve a patron image, we can call Koha::Patron::Images->find or
Koha::Patrons->find->image
Both will return a Koha::Patron::Image object.
Test plan:
1/ From the patron/member module, open all tabs on the left (Checkouts,
detail, fines, etc.)
The image should be correctly displayed.
2/ At the OPAC, on the patron details page (opac-memberentry.pl) the
image should be displayed as well.
3/ Same on the sco module.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The 'borrower' should not be used anymore, especially for new code.
This patch move files and rename variables newly pushed (i.e. in the Koha
namespace).
Test plan:
1/
git grep Koha::Borrower
should not return code in use.
2/
Prove the different modified test files
3/ Do some clicks in the member^Wpatron module to be sure there is not
an obvious error.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as described. Tested with Circulation, Members/Patrons, Discharge,
Restrictions modules and the must common functionalities
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
This patch allows to resend both sent and failed messages.
With messages in 'sent' status, we have to be careful not to accidentally send
sent messages again. With the previous patch using GET request, this was likely
to happen because of browser storing the GET parameters.
This patch changes request method from GET to POST. Instead of a simple link,
we now have a form element.
In notices.pl we redirect back to notices.pl, because with POST there is a risk
of resending the message accidentally by form resubmission at refresh.
To test, find/create a Patron that has sent or failed notices in message_queue:
1. Enable EnchancedMessagingPreferences system preference
2. Go to Patrons -> Notices
3. In the Notice column, click the title of the sent or failed message
4. Observe that there is nothing for resending the sent or failed message
5. Apply the patches.
6. Reload Notices page and repeat step 3
7. Observe that there is now a link "Resend" in the Status-column
8. Click Resend
9. Observe that the message gets into 'pending' status
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
The C4::Letters module does not have a GetMessage subroutine, which
could be quite useful.
This patch adds it and simplifies the code added by the previous patch.
It also adds a few tests and fixes POD typos.
Note that ResendNotice only resends failed messages. This will avoid to
resend already sent messages (using an url from the browser history for
instance).
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
This patch adds a link 'Resend' under a notice in 'failed' status
in the Patron's Notices tab.
By clicking the link, we will request notices.pl with parameter
"resendnotice=XXXXX" where XXXXX is message_id. In notices.pl,
we then check whether the given message is actually in 'failed'
status. If so, we use the C4::Letters::ResendMessage(123) to
change the status of the message into 'pending'. This way it
will be processed again by the cronjob process_message_queue.pl.
To test, find/create a Patron that has failed notices in message_queue:
1. Enable EnchancedMessagingPreferences system preference
2. Go to Patrons -> Notices
3. In the Notice column, click the title of the failed message
4. Observe that there is nothing for resending the failed message
5. Apply patch.
6. Reload Notices page and repeat step 3
7. Observe that there is now a link "Resend" in the Status-column
8. Click Resend
9. Observe that the message gets into 'pending' status
Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
* Use ->id instead of ->branchcode when possible to eliminate use of that nomenclature
* Fix bad use of ->branchcode to ->{branchcode} for unblessed hashref version of Koha::Library
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
C4::Branch::GetBranchDetail retrieved library infos, it could be easily
replaced with Koha::Libraries->find
When this change needs other big changes, the unblessed method is
called, to manipulate a hashref (as before) instead of a Koha::Library
object (for instance when $library is sent to GetPreparedLetter).
Test plan:
1/ Print a basket group, the library names should be correctly
displayed.
2/ Enable emailLibrarianWhenHoldIsPlaced and place a hold, a HOLDPLACED
notice will be generated (focus on the library name)
3/ Edit a patron and change his/her library
4/ Generate the advanced notices (misc/cronjobs/advance_notices.pl) and
have a look at the generated notices
5/ Same of overdues notices
6/ Set IndependentBranches and use a non superlibrarian user to place a
hold. The "pickup at" should be correctly filled.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
C4::Members::getidcity and C4::Members::GetCities simply retrieved
cities info from the cities table.
The job done in members/memberentry.pl looked really weird and complicated.
Either I have missed something, or this patch can simplify it.
The expected behavior is:
1. Create a new patron => No city selected
2. Edit an existing patron => The borrowers.city value is selected
3. Add a guarantee => The borrowers.city of the guarantor is selected
4. Edit a guarantee => The borrowers.city of the guarantee is selected
Test plan:
Confirm that the expected behaviors are the ones before and after this patch.
Signed-off-by: Natasha <tasham_8@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Test Plan:
1) Apply this patch
2) Go to circulation.pl
3) Ensure you can still override renewal limits with pref enabled
4) Ensure you can not override renewal limits with pref disabled
5) Go to moremember.pl
6) Repeat steps 3-4
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Same fix as before for the "Write off" button next to the "Pay" button.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
When a payment is made individualy, the library used to record this
payment is randomly picked from the library list.
This is because C4::Branch::GetBranch looks at 1. the $branch variable
sent by the template, wich does not exist, then 2. the branchname
cookie, which does not exist neither, then 3. get the first branchcode
from a list of keys (non ordered).
To reproduce:
- Create a manual invoice for a patron
(members/maninvoice.pl?borrowernumber=XXXX)
- Pay this fine using the "Pay" button of the corresponding line from
the members/pay.pl?borrowernumber=XXXX page
Look at the statistics table:
select * from statistics order by datetime desc limit 10;
The branch value of the first line might not correspond to the library
you were using to pay the payment.
Test plan:
Apply this patch, repeat the steps above and confirm that the library
picked is now the one used to pay.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised
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>
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>
On the 3 following pages, the patron image was not displayed:
members/discharge.pl
members/pay.pl
members/paycollect.pl
Test plan:
Apply this patch and confirm the image is now displayed
Followed test plan, image displays as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
To test:
1) Go to patron Details page (ie http://localhost:8081/cgi-bin/koha/members/moremember.pl?borrowernumber=51)
2) Confirm that '(x years)' is showing next to the Date of Birth and is correct according to DOB (ie if DOB: 30/11/1996, Age: 19 years)
3) Edit date of birth to be a month later (ie from 30 November to 30 December) so that, as of the date you are testing, the patron has not had their birthday yet
4) Confirm that age changes to be one year younger
5) Edit date of birth to be a different year
6) Confirm that age changes accordingly
Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
If a patron's privacy settings are set to "Never" for keeping a reading history, "Export today's
checked in barcodes" returns an empty file. This patch does not allow to export in such case.
To test:
- Apply patch
- Check out / check in in some items
-Test toolbar:
- On user's detail page, go to More->Export today's checked in barcodes
- Verify that the menu item does not appear if syspref 'intranetreadinghistory'
is set to 'Don't allow'
- Verify that the menu item appears if syspref 'intranetreadinghistory'
is set to allow and
- that the menu item is grayed out with a tooltip if the user has set privacy
settings to never keep a reading history
- that the menu item works as before if user's privacy settings allow reading history.
- Test left tab "Circulation history":
- Verify that the left tab "Circulation history" does not appear if syspref
'intranetreadinghistory' is set to 'Don't allow'
- Verify that the tab appars if syspref 'intranetreadinghistory' is set to 'Allow' and
- that a message appears if user's privacy settings do not allow to keep the reading history
- that the export works as before if user's privacy settings allow to keep the reading history
(Amended and changed test plan for comment #9)
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Test - Check file for 'konw', notice no instance
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Typo fixed
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Test- search for writen, if not found patch successful
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Typo fixed
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Gus: You should try git grep writen one more time :)
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
No other patches in process modify member-password.pl, now would be
a great time to tidy it!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
The patron's information displayed in the member module
(includes/circ-menu.inc and includes/member-display-address-style-*.inc)
are not always displayed the same way.
Sometimes the streetnumber is missing, sometimes it's the streettype.
Sometimes the streettype is after the address, sometimes before...
Test plan:
Go on a patron detail page, and open all the tabs on the left (Check
out, Fines, Notices, etc.)
Without this patch, the patron's info displayed will differ from one page to
another.
With this patch, they will be displayed the same everywhere.
Followed test plan, works as expected. (Tested both patches together.)
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
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>
To test:
1) Add a hold to a patron
2) Go to patron page
3) Click Print Summary
4) Confirm that 'Pending Holds' table displays with correct information under appropriate headings (should be Title, Author, Placed on (reserve date), Expires on (expiration date), and Pick up library)
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
When navigating the tabs in the patron account, for 2 tabs the
patron category description is missing above the tabs.
To test:
- Go to a patron account in staff
- Click through the tabs
- Verify that for Checkouts and Fines the category description
is missing above the tabs
- Apply patch
- Verify the description is now shown
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Find another place where there is a patron search (add user to a basket,
add users to a fund or edit owner of a fund, set a guarantor to a child,
etc.).
Do a search a confirm that the results are now sorted by name instead of
cardnumber.
Signed-off-by: Nicole Engard <nengard@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When userid is not provided when creating a new patron, it is generated
using surname and firstname. The bug is when userid is defined in
syspref BorrowerUnwantedField, the input text is missing in patron
creation form. When saving you always get an alert message :
"Username/password already exists". No patron can be created.
This patch corrects by adding this case to userid generation conditions.
Test plan :
- add 'userid' in syspref BorrowerUnwantedField
- try to create a new patron : /cgi-bin/koha/members/memberentry.pl
- there is not input text for userid
- choose non-existing surname and firstname
- click on save
=> Without patch : patron is not created, you see the alert message
"Username/password already exists"
=> With patch : patron is created, userid is generated with surname
and firstname
- remove 'userid' in syspref BorrowerUnwantedField and check it can be
defined in patron creation form
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
The issue is there, and this patch fixes it.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Some librarians would like to be able to print an overdues slip from the
staff intranet. This slip would be defined as the print transport
version of the ODUE slip.
Test Plan:
1) Apply this patch
2) Locate a patron with overdues
3) Define a print version of the OVERDUES_SLIP slip
4) Try Print > Print overdues
Signed-off-by: Amy Purvis <APurvis@galencollege.edu>
Signed-off-by: Laurie McKee <lmckee@littleelm.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch removes warnings when printing a summary from a member's
detail page, like:
- use of uninitialized value in sprintf
at /usr/share/kohaclone/members/summary-print.pl line 47
- Use of uninitialized value $roadtype in concatenation (.) or string
at /usr/share/kohaclone/members/summary-print.pl line 61
- Use of uninitialized value in addition (+)
at /usr/share/kohaclone/members/summary-print.pl line 87
- Argument "2015-11-03 23:59:00" isn't numeric in numeric comparison
(<=>) at /usr/share/kohaclone/members/summary-print.pl line 103
To test:
- Apply patch
- Go to a detail page with a member who has a lot of fines
- Print summary
- Verify that warnings like the ones above do no longer appear.
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Have been able to see those warnings in Apache log file, and notice
their disappearance after applying this patch.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Behaviour now is:
IndependentBranches = Prevent
or
IndependentBranches = Don't prevent,
IndependentBranchesPatronModifications = Prevent:
You will always only see the modification requests of your branch's patrons.
IndependentBrnaches = Don't prevent,
IndependentBranchesPatronModifications = Don't prevent
All modification requests are shown.
Link to patron record works and cardnumber is shown.
IndependentBranches = OFF - use the new preference.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
By not limiting the patron modification lists by branch, it can quickly
become overwhelming for a librarian. This patch makes the following
modifications:
* Only superlibrians will see the full list of borrowers with pending
modifications.
* Adds the patron cardnumber after the patrons name on the modification
list.
* Adds a link to the patron's record from the modification list.
Test Plan:
1) Apply this patch
2) Set up some pending modifications for two branches
3) Log in to the staff intranet as one of those branches
4) You should note the number of pending modifications counts
only your logged in branch's patrons
5) Click the link, you should only see your logged in branches
patrons in the pending modifications list.
6) You should note the cardnumber is displayed next to the patron name
7) You should note the "View record" link below each patron's name
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Comments on last patch.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
print slip and show the member detail page, the 3 dates date of birth,
date enrolled and date of expiry should be displayed correctly.
Followed test pan, 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: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised. Tested with the three values from dateformat syspref
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch removes C4::Dates from members/printfeercpt.pl
To test:
- Go to a patron's fines (members/boraccount.pl) and make sure that
he/she has made a payment
- Select 'Print' in the payment's line
- Verify that the payment date on the slip displays correctly
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised. Date displayed 2015-10-08
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
These 2 fields are not used anymore, but we want to keep them anyway.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch removes C4::Dates from members/moremember.pl
To test:
- Go to Details page of several members
- Verify that all dates display OK, including restrictions
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised. All dates displayed OK
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch removes C4::Dates from members/memberentry.pl
To test:
- Apply patch
- Add and edit patrons with and without birthdate as
mandatory field (syspref BorrowerMandatoryField)
- Verify that dates (birtdate, registration, expiration)
display and are stored correctly
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised. Tested with syspref BorrowerMandatoryField and
table borrowers.dateofbirth
Bug 14924 - (follow-up) Add date validation using eval
This patch adds a date validation (see comment #3).
To test:
- Apply patch
- Create a new user or edit an existing user
- Try valid dates for date of birth
- Try invalid dates as 0000-00-00 or 32/01/1970. You can can
copy/paste such strings to the date field, ignore the warning
message and submit. Verify that after submit you get a message
"Date of birth is invalid"
- Try the same with enrollement /expiry dates
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised. Tested with invalid dates.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Amended patch: I have splitted them to make them much more readable
(some lines were removed then added).
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This is a(nother) vestige of Koha (2.2?).
This patch removes unused code related to the 'ethnicity'.
In detail:
There is no way to fill the ethnicity table.
There is no way to fill the borrowers.ethnicity and borrowers.ethnotes.
BUT if borrowers.ethnicity exists, the value is displayed on
members/moremember.pl (and only here).
Test plan:
Apply this patch and confirm there is no regression on
adding/updating/deleting patrons.
Note that you don't see the ethnicity value on the moremember.pl page even if a patron has it.
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
iIf a patron is renewed from the circulation module, the librarian
should be redirected to the circulation module.
This works correctly if the renew is done from the patron module
(members).
This is caused by a typo in the template: desintation vs destination.
This patch also removes the cardnumber parameter to the setstatus.pl
script, it is not needed given that borrowernumber is always passed.
This has a good side-effect, it will fix bug 14691. The cardnumber does
not exist anymore, so no need to escape it :)
Test plan:
0/ Do not apply this patch
1/ Create a patron with a cardnumber with a quote (rm'me) and another
one without a quote (rmme)
2/ Go on the checkouts page (circ/circulation.pl)
3/ Renew the 2 patrons
=> With rm'me you are redirected to the circ module - ok
=> With rmme you are redirected to the member module - nok
4/ Go on the patron detail page (members/moremember.pl)
5/ Renew the 2 patrons
=> you are redirected to the member module - ok
6/ Delete the patrons
=> Nothing happend with rm'me, there is a JS error on the page - nok
=> rmme is deleted - ok
7/ Apply the patch and recreate rmme
8/ Repeat 2, 3, 4, 5
=> You are redirected to the correct module
9/ Delete the patrons
=> They are successfully deleted
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Followed the test plan, works as advertised. (I did have some problems
initially, but that was caused by me not using the interface in
English...)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Currently, once a user is discharged, lifting the discharge debarment does
not allow the user to ask for a discharge again.
This patch adds the ability for a user to be discharged several times and to
keep an history of the discharges.
Test plan:
- As a user, ask for a discharge.
- As a librarian, allow the discharge.
- Check that the requested and validated dates appear on the discharge panel of the borrower in the admin interface.
- Lift the discharge debarment of the user.
- Check that you can repeat these steps and that the new discharges are added in the discharge panel of the borrower in the admin interface.
Please note that you will need to run misc/devel/update_dbix_class_files.pl after the SQL update.
Adding a primary key to the discharges table was mandatory for DBIX::Class to be able to query with order_by.
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Test plan: See Bugzilla.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Script memberentry.pl contained a similar line.
Solution is simpler here.
Test plan:
[1] Add, change or clear the sms number at staff side.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
On the patrons home page, the dropdown list is not populated.
Test plan:
1/ Go on the patrons home page (members/members-home.pl)
2/ Launch a search
3/ The dropdown list close to "Add selected patrons to" should contain
all your patron lists
NOTE: Initially tested with both which created lists.
git reset --hard origin/master
And then dropdown list was missing them.
Applied just this one, and they were listed.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Bug 13970 removed some useful code to automatically set the guarantor
when creating a child.
But finally there is a better way to do the job, we just need to assume
that only children or professional can have a guarantor.
Test plan:
1/ Create an adult patron and add a child.
2/ The guarantor info should be retrieved and set on the child creation
page.
3/ Create an organization and add a child
4/ The guarantor info should be retrieved and set on the adult creation
page.
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
This patch catches both cases, thanks Jonathan!
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
There is no permission needed to access the patronimage.pl script.
This means anybody cans access to the patron's images.
Test plan:
Add an image to borrowernumber 42 and call
/cgi-bin/koha/members/patronimage.pl?borrowernumber=42
If you are logged in with borrowers permissions, you will see the image,
otherwise you will get a blank page with a 403 header.
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
To test:
1) Go to any patron's page, click Change password
2) Notice warns in error log
3) Apply patch, reload page
4) Click Change password
5) Notice warns are gone and page still works correctly
Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
If a patron has duplicate accountno's for two different fines in Koha this will trigger the error
usi_escape: Unmatched [ in regex; marked by <-- HERE in m/([ <-- HERE ])/ at (eval 133) line 1.
upon attempt to pay. How those accountno's get duplicated is unknown, but considering accountno
is somewhat vestigial at this point in time, it would be much more sensible to use accountlines_id
which is has guaranteed uniqueness at the database level.
Test Plan:
1) Create a patron with 2 fines
2) Edit the accountno's for those fines and set them to 0
3) Attempt to pay one, note the error
4) Apply this patch
5) Refesh the page
6) Attempt to pay one, no error this time!
7) Test Pay, Write off, Pay amount, Write off all, and Pay selected
Signed-off-by: Deborah Duce <deborah.duce@huntsvillelibrary.ca>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
This patch adds server-side & client-side validation for email
form fields in the members/memberentry -view and in the
opac/memberentry-view (bootstrap).
I recently added simple validation for phone number and email address fields
for our in-house koha and saw this old bug: I'm open to any ideas on how
to do this better. Validation for phone numbers would be easy to add on
top of this but I left it out since this bug is only about the email
fields.
To test:
1) Select a member and go to any of the edit forms with email fields
(Primary info, "Library use", "Alternate address", "Alternative
contact").
2) Disable javascript in the browser in order to test server-side
validation and try to input invalid emails in each of the email form
fields.
3) Confirm that an invalid address is catched from any of the email
fields, an alert shown for each invalid address and that the member's
information was not updated with invalid data.
4) Enable javascript in the browser.
5) Confirm that the jquery validation plugin caches invalid addresses
from any of the email fields and that you cannot send the form before
correcting the problem.
6) Perform the same tests for the opac-memberentry-view.
Note: as the jQuery validation plugin doesn't exist in the bootstrap
folder, I just copied it over from the staff-client folder -how to deal
with this?
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I have undone the changes to opac.css so that they can be submitted as a
separate patch. I have some other follow-ups to make as well.
Signed-off-by: Nicole Engard <nengard@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Jonathan Druart agreed that C4::Input is vestigial code that should be removed.
Here is how I checked. First I found where C4::Input was used. Then, I checked
what functions are in the package: just checkdigit. Then, I confirmed that
checkdigit is not used at all in any acquisition, administration, or member
related perl scripts. Lastly, I took a look at our supposed test file for the
package. It was painfully sparse.
As such, this patch removes the test file and the package file, and removes
C4::Input references from these six files:
- acqui/addorderiso2709.pl
- acqui/basketgroup.pl
- acqui/neworderempty.pl
- acqui/uncertainprice.pl
- admin/aqplan.pl
- members/memberentry.pl
NOTE: neworderempty had 3 lines of it?! Didn't anyone see that?!
Here is the output of what I did to confirm this correction:
mtompset@debian:~/kohaclone$ git reset --hard origin/master
HEAD is now at 6e9086f Bug 3206: (QA followup) missing comma on sysprefs.sql
mtompset@debian:~/kohaclone$ git grep C4::Input
C4/Input.pm:package C4::Input; #assumes C4/Input
C4/Input.pm:C4::Input - Miscellaneous sanity checks
C4/Input.pm: use C4::Input;
acqui/addorderiso2709.pl:use C4::Input;
acqui/basketgroup.pl:use C4::Input;
acqui/neworderempty.pl:use C4::Input;
acqui/neworderempty.pl:use C4::Input;
acqui/neworderempty.pl:use C4::Input;
acqui/uncertainprice.pl:use C4::Input;
admin/aqplan.pl:use C4::Input;
members/memberentry.pl:use C4::Input;
t/Input.t: use_ok('C4::Input');
mtompset@debian:~/kohaclone$ grep sub C4/Input.pm
sub checkdigit ($;$) {
my $temp2 = substr($infl,$i,1);
if ($rem eq substr($infl,8,1)) {
} # sub checkdigit
mtompset@debian:~/kohaclone$ grep checkdigit `find acqui -type f`
mtompset@debian:~/kohaclone$ grep checkdigit `find admin -type f`
mtompset@debian:~/kohaclone$ grep checkdigit `find members -type f`
mtompset@debian:~/kohaclone$ cat t/Input.t
use strict;
use warnings;
use Test::More tests => 1;
BEGIN {
use_ok('C4::Input');
}
Apply this patch, and the output of git grep C4::Input will be empty.
Run koha qa test tools (kind of overkill)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
On moremember, the button is displayed for Organisations.
To be consistent, it should be displayed on the circulation page too.
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jason Robb - SEKLS (jrobb@sekls.org)
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Currently, when generating a discharge letter, branches fields are not translated in the letter (<<branches.branchname>>, <<branches.branchaddress1>>, etc.)
This patch fixes that.
How I tested:
- Set syspref 'useDischarge' to 'allow'
- Go to Home > Tools > Notices & Slips
- Edit DISCHARGE, add to 'Email message':
<p><<branches.branchname>><br />
<<branches.branchaddress1>><br />
<<branches.branchaddress2>><br />
<<branches.branchaddress3>><br />
<<branches.zip>> <<branches.city>><br />
</p>
- Go to detail page of a patron > discharge
- Click 'Generate discharge'
- Verify that the PDF contains the information above.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Working on bug 13497 and bug 9314, I run into some Koha vestiges.
The category_type parameter should not be passed to memberentry.
On creating a new patron, the categorycode should be passed, and on
editing, it's useless. We can work with the borrowernumber and retrieve
these values.
Details of the changes:
- members-toolbar.inc: Remove the category_type parameter passed to
memberentry.pl
- memberentrygen.tt: Just remove the useless category_type parameter on
editing a patron. Also remove the unused one passed to
guarantor_search.pl.
- tables/members_results.tt: the borrowernumber is enough to edit a
patron.
- memberentry.pl: check_categorytype is never used in the template, all
the process to calculate/retrieve it is unnecessary.
- members/nl-search.tt: The borrowernumber is enough to edit a patron.
Test plan:
Try to create and edit patrons and verify that
- the guarantor search still work
- the form (memberentry) behave as before
Edit a patron from the nl-search.pl script (Magnus?)
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
On top of 9314 (13497 already pushed)
No evident regressions found, add/edit patron works,
search/set guarantor works.
Cant test nl-patron.pl save for exec it.
prove -v t/NorwegianPatronDB.t runs
No koha-qa errors
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since the pref AddPatronLists has been removed in bug 13497, the code
related to type_only and category_type in memberentry.pl is useless.
Test plan:
Confirm you don't the information message.
You can also confirm that the message was wrong and nothing was saved.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Dead code removed, no errors
Think that bug description can be updated to commit message
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The check on the ages limits is only done when the dateofbirth field is
mandatory, which does not make any sense.
This check should be done when the field is filled.
Test plan:
1/ Remove the dateofbirth field from the BorrowerMandatoryField pref
2/ Create a patron category for teenager (say between 12-17y)
3/ Try to create a patron in this category outside the range of the ages
limits.
You should not be able to do it.
Signed-off-by: Christopher Brannon <cbrannon@cdalibary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The branchcode and categorycode parameter names are too common and are
confusing.
To remove the ambiguity, this patch renames them with branchcode_filter
and categorycode_filter.
Test plan:
1/ Go on the patron home page (members-home.pl)
2/ Fill the library and category dropdown list in the header search
3/ The patron result list appears and the filters (on the right) are
correctly set with what you have selected.
Make sure the ones in the header are also correctly selected.
4/ Click on a patron
5/ On the patron detail page (moremember.pl), the dropdown lists in the
header are not preselected.
Signed-off-by: Nicole Engard <nengard@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
A lot of page uses the patron search box header include (git grep
patron-search.inc for the list) and the branch and category lists are
not generated for all of them.
For instance, on a patron detail page, there is a [+] link, but nothing
append on clicking on it.
This patch add a new template plugin "Categories" to get all patron
categories from the templates.
Test plan:
1/ Verify the [+] is working on all patron page (if that works for 2,
that should work for all).
2/ Launch a search from the header box and verify the library and
category dropdown lists select the correct value.
3/ Launch a search on the patron search page (patron home) and verify
the search is working correctly on selecting a category and/or a library
Followed test plan. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nicole Engard <nengard@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To get rid of SQLHelper, we should not use this C4::Members::Search anymore.
Test plan for Magnus :)
0/ Enable the pref you need to use the Norwegian national library card ft
1/ Go on the members/nl-search.pl page and search for patrons.
2/ Make sure you search by card number and by "social security number"
Signed-off-by: Magnus Enger <magnus@enger.priv.no>
Searching works the same with and without the patch. Thanks Jonathan!
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds a check to prevent deleting the user's own account.
Additionali it fixes a "missing link" in moremember.pl and wrong comparisions in moremember.tt regarding other forbidden deleting.
To test:
- Apply patch
- Create a user with sufficient privileges to delete users
- Log in as this new user
- Try to delete this user. Confirm message box "Are you sure..."
- Confirm that you get a message "Not allowed to delete own account" and that the user still exists.
Bonus test:
Try to trigger other forbidden deletions (see members/deletemem.pl): 'CANT_DELETE_STAFF', 'CANT_DELETE_OTHERLIBRARY', 'CANT_DELETE'
(You can fake it by using an URL like: /cgi-bin/koha/members/moremember.pl?borrowernumber=115&error=CANT_DELETE_STAFF etc.)
Without patch, no message appears. With patch, messages appear as appropriate.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
NOTE: Attempted all CANT combinations. From reading the code,
this is kind of an important patch, because I'm not sure
deleting error messages work at all right now based on what
I read.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If error occurs when generating the pdf, it would be better to get an
encapsulated error instead of the "software error" message in the pdf
file.
To test this patch I added this change:
b/Koha/Borrower/Discharge.pm
-115,6 +115,7 @@ sub generate_as_pdf {
say $html_fh $html_content;
close $html_fh;
my $pdf = PDF::FromHTML->new( encoding => 'utf-8' );
+ $html_path .= "poeut";
$pdf->load_file( $html_path );
$pdf->convert;
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch should be applied to work with bug 11944.
If you don't have 11944 yet, just don't apply this patch.
Note that the line
binmode(STDOUT);
in pl files is mandatory.
It comes from bug 11944 that adds the line
binmode( STDOUT, ":utf8" );
in C4::Templates::gettemplate.
Signed-off-by: Lucie <lucie.rousseaux@dracenie.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch is the main patch. It adds new package and files for the new
pages (opac-discharge, members/discharge and members/discharges).
At the intranet, it is now possible to generate a discharge for a patron.
At the opac, a patron can request a discharge and a discharge if it has
been validated by a librarian.
Requirements:
The perl module PDF::FromHTML
New sysprefs:
- useDischarge: Allows librarians to discharge borrowers and borrowers
to request a discharge
New letter with a letter_code DISCHARGE.
Test plan:
- Switch on the syspref useDischarge.
- Verify a new tab appears in the patron page (intranet and opac).
- Verify the discharge cannot be generated if the patron has issues.
- Verify the patron can request a discharge from it's opac area.
- The request appears on the main page (intranet).
- Generate the discharge from the intranet.
- Try to download it (from the opac and the intranet).
Signed-off-by: Lucie <lucie.rousseaux@dracenie.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch displays the address information in the left column of the patron's pages using the new system preference.
The address is formatted in member-display-address-style-us.inc and member-display-address-style-de.inc
To test:
- Apply patch on top of 1st and 2nd patch
- Select 'German style' in system preference 'addressformat' in I18N/L10N
- Verify that the address information displays properly in the left column of all patron's pages.
- Verify that the address displays properly in the main area of moremember.pl as well (Note: In right column, Alternate address /contact are not yet touched))
- Switch system preference to US style, repeat checks
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
AMending without changes to put this patch at the end of the patch list / Marc
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
On printing the summary from the patron account, the hours are not
displayed if needed.
The as_date_due flag should be set to display it correctly.
Problem, GetPendingIssues modify the value retrieved from the database.
In order to not add regression and check all calls to GetPendingIssues,
this patch backup the value before the change.
Test plan:
Check some items out, specify a hourly loan for some.
Click on print > print summary and confirm the date due are correctly
formatted.
Followed test plan. Date + time display as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
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>
The pref AddPatronLists does not work as expected if 'generic' is
selected.
Indeed a patron should be linked to a valid patron category (see the
constraint borrowers_ibfk_1 in the DB structure).
Test plan:
0/ Confirm that the AddPatronLists does not work as expected if you choose
the generic patron types.
1/ Delete all you patron categories and check that the interface invites
you to create one.
2/ Confirm that you are able to create a patron and to link it to a patron
category you have created.
I could not verify step 1/, because at least one Patron category
can not be deleted (Staff, since I'm logged in as a Staff patron
and you can not delete categories that are in use).
Tested 0/ and 2/
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes QA script and tests.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch fixes the regressions introduced by the previous patches.
If you have tested all in once, you didn't see them.
It introduces library, category and "first letter" filters.
Test plan:
1/ On all pages impacted by previous patches + new order empty (link patron to
an order) + guarantor search
2/ Add / Select patron to the list
3/ Use the filters
4/ Confirm there is no regression
Tested together with other patches.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This column is not in used in the Koha code and could be removed.
Test plan:
Verify the branch is correctly displayed on the circulation history
(members/readingrec.pl) and that both reports Most-cisulated items
(cat_issues_top.pl) and Avg checkout (issues_avg_stats.pl) work as
before.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No problems found.
Fixed wrong table name on updatedatabase.pl and a tab char.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script.
Checked issues and returns are still working correctly.
There is no mention of issuingbranch in the codebase.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This code is never used. The permission to delete a patron is now done
in members-toolbar.inc using CAN_user_borrowers.
It's the good way to do.
Test plan:
git grep CANDELETEUSER
should not return any result
Followed test plan. No CANDELETEUSER found.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Previous patch removed the name column, it's a regression.
This patch reintroduces it.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch is the main patch.
The "common" template is improved to allow different type of picking:
"add" or "select".
The first one appends a patron to a list, the second one selects the
patron and close the result search window.
The members/guarantor_search.pl has completly changed but is quite the
same file as acqui/add_user_search.pl. Both should exist: they don't
belong to the same module (acqui vs members), the picking type is
different (add vs select) and the columns are not the same.
The changes in the common template are very powerful, it's now possible
to list the column we want! This will be very useful for further
reusability.
Before this patch, all patrons mathing the pattern were return. Now only
the first 20 are (depends on the DataTables selected value).
For QA: This patch introduces a new template plugin "To", for now it
permits to convert a perl structure to json. In the idea, it could
permit to convert foo to bar too.
Test plan:
1/ Verify there is no regression in the guarantor search. When the
selection has been done, all data from the guarantor should fill the
form in the "main address" section.
Note that the request is done when the search input in not empty and the
user stop to write for 1 sec.
2/ Verify there is no regression on the 2 other pages where this patron
search is used: link a patron to an order and to a basket (in the
acquisition module).
Signed-off-by: Morag Hills <the.invinnysible.one@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When editing a Patron's messaging preferences or borrower attributes, one cannot
save changes because 'userid' is not given as a parameter.
It shouldn't, but the
Check_Userid($newdata{'userid'},$borrowernumber) -check must have it.
REPLICATE THE ISSUE:
1. Find a Borrower.
2. Go to the details-tab.
3. Under "Patron messaging preferences" click edit to edit just the messaging
preferences.
4. Just save, no need to make any modifications.
5. Observe the error "Username/password already exists"
This happens to all/most of the sub-forms in the Borrower's Details-view.
AFTER THIS PATCH:
Check_Userid() get the $userid from the new parameters, or if not present, from
the koha.borrowers-table.
TEST FOR REGRESSION:
1. Edit a borrower normally. Notice no errors.
2. Edit a sub-form (Alternate address/Patron messaging preferences). Notice no
errors.
DISCLAIMER: You are free to steal/rip/modify/hack this patch to your soul's
extent without my permission. As long as it makes to Koha I am happy.
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: Tomas Cohen Arazi <tomascohen@gmail.com>
Date sorting of charges under Patron -> Fines -> Account is done based
on formatted dates, so sorting is broken depending on your dateformat
system preference. This patch implements the standard "title-string"
date sorting method.
To test, apply the patch and view the Account tab. Test sorting of
charges under various settings of the dateformat system preference. Date
sorting should work correctly in all cases.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described and fixes sorting problem.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To reproduce, edit, index notice with utf-8 char and search for it
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 9811 removes useful code.
Actually the AddPatronLists pref is not sent to the template from
members/member.pl.
To fix this issue, we can use the existing not clean way, or compare the
syspref value directly in the template. This second solution is
implemented in this patch.
Test plan:
1/ Set the AddPatronLists pref to 'specific'
2/ On the patron home page (members/members-home/pl), the patron search
result page (members/member.pl after launching a search) and on the
checkouts page/patron search result (circ/circulation.pl after searching
a patron using the check out), verify that the patron category list is
the specific ones.
3/ Test there are no regression with the AddPatronLists pref set to
'general'.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Works as described and fixes the problem.
Note: I am not sure if AddPatronLists makes sense -
if you set it to general patron types, it still preselects the
wrong category type (tried organization, a child patron category
was selected). Also the name is confusiong nowadays with the
Patron list feature.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Test scenario:
1. ensure that extended patron attributes are turned on in system preferences
2. find borrower which has fine to pay, and click on pay button
3. verify application error
4. apply patch and verify that application error is gone
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Without patch:
-------------
Make payment for patron who has fines
Select the Pay Amount button and add a note in the note box.
Select confirm
Result: The note does not display in list
With patch:
----------
Result: The note displays in list
Bonus testing: The note is included in system logs as well (Home:Tools:Logs)
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 2546 removes the description DB field value in some case (3.15.00.003).
But the receipt generated by scripts members/printfeercpt.pl and
members/printinvoice.pl displays this field.
When the description field is empty, the default value (based on
accountlines.accounttype) should be displayed.
Test plan:
- Generate and pay some different kinds of fees for a patron without
filling the 'description' field.
- In Fines>Account, click on the 'print' link.
- Before this patch, the "description of charges" values is empty if no
description was given.
It is a regression introduced by bug 2546, a default value was
inserted in the description field depending on the account type
selected.
- After this patch, the "description of charges" values should be based
on the account type. The string display on printing receipt should be
the same as on the account screen (staff and opac).
Note for QA: If removed the "payment" key, it is not used in template
and generated a warning ("odd number of elements...").
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
This fixes the display of payments and other charges on the
fines slip.
Note: This patch fixes a line where the description in the
database was still updated to say "Payment thanks" for partial
payments. It might be worth to do a follow-up correcting the
accountlines table and removing the unwanted comment (see bug 2546).
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If a patron has guarantees, always display them on the patron summary,
even if the patron is of a type that ordinarily would have them.
For example, at present you can cannot directly add a guarantee to
a staff record the way you can do for an adult patron, but if you create
a juvenile patron and add a guarantor to it, you can override that
restriction. Note that this patch ignores whether that is strictly
desirable behavior.
To test:
[1] Create a juvenile patron. While editing it, make a staff
account a guarantor of the new patron.
[2] View patron details for the staff account. Note that the
juvenile patron is not displayed as a guarantee.
[3] Apply this patch.
[4] Refresh details for the staff account. The juvenile should
now show up.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Galen patch works as described. The way it's implemented seems sensible.
Whatever the reason why a patron has guarantes, it make sense to display
them. So it's better to check the count of guarantes rather than the
current patron type to decide to display guarantes.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, small change, no regressions found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
This successfully fixes the problem observed when a patron has no
checkouts.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
* Makes the status column display "Overdue!" if overdue
* Fixes the due date formatting
* Sorts the checkouts by date due ( oldest to newest )
Note: I found no evidence that this data was previously sorted,
so I kept it simple. Sorting based on system preferences could
be a future enhancement.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
This fixes the issues described for patrons with existing checkouts.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
A patron's print summary should contain a list of checked out items
as it did in 3.16.2 and earlier.
Please note, as of 3.16.2 reserves were no longer part of the print
summary and thus are not part of this bug fixing patch.
Test Plan:
1) Find a patron with checked out items
2) Choose Print -> Print summary
3) Note the lack of a list of checkouts
4) Apply this patch
5) Reload the page
5) Print the summary again
6) Note the list of checkouts
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Works as described, apart from the missing status information
that Owen already noted on the bug.
Passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
1) Be more careful when checking the NorwegianPatronDBEnable syspref.
Before:
if ( C4::Context->preference('NorwegianPatronDBEnable') == 1 ) {
After:
if ( C4::Context->preference('NorwegianPatronDBEnable') && C4::Context->preference('NorwegianPatronDBEnable') == 1 ) {
This should avoid complaints if the syspref is not initialized.
2) Fix some empty =head2 POD sections
3) Fix some indentation in patrons.pref, to make xt/yaml_valid.t happy
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
I couldn't find any regressions with adding, editing and deleting members.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch makes it possible to sync patron data between Koha and the
Norwegian national patron database, in both directions.
In order to use this, the following information is necessary:
- a username/password from the Norwegian national database of libraries
("Base Bibliotek"), available to all Norwegian libraries
- a special key in order to decrypt and encrypt PIN-codes/passwords,
which is only available to Norwegian library system vendors
- a norwegian library vendor username/password
See http://www.lanekortet.no/ for more information (in Norwegian).
While this is of course an implementation of a specific synchronization scheme
for borrower data, attempts have been made to prepare the ground for other sync
schemes that might be implemented later. Especially the structure of the new
borrower_sync table might be reviewed with an eye to how it might fit other
schemes.
To test:
Since the password and cryptographic key needed to use this functionality
is only available to Norwegian library system vendors, only regression testing
can be done on the submitted code. Suggested things to check:
- Apply the patch and make sure the database update is done. This should add
the new "borrower_sync" table and five new systmpreferences under the
"Patrons" > "Norwegian patron database" category:
- NorwegianPatronDBEnable
- NorwegianPatronDBEndpoint
- NorwegianPatronDBUsername
- NorwegianPatronDBPassword
- NorwegianPatronDBSearchNLAfterLocalHit
- Check that patrons can be created, edited and deleted as usual, when
NorwegianPatronDBEnable is set to "Disable"
- Check that the new tests in t/NorwegianPatronDB.pm run ok, e.g. on a
gitified setup:
$ sudo koha-shell -c "PERL5LIB=/path/to/kohaclone prove -v t/NorwegianPatronDB.t" instancename
- Check that all the other tests still run ok
- Check that the POD in the new files itroduced by this patch looks ok:
- Koha/NorwegianPatronDB.pm
- members/nl-search.pl
- misc/cronjobs/nl-sync-from-koha.pl
- misc/cronjobs/nl-sync-to-koha.pl
- t/NorwegianPatronDB.t
Sponsored-by: Oslo Public Library
Update 2014-09-18:
- Rebase on master
- Split out changes to Koha::Schema
- Incorporate new way of authenticating with NL
Update 2014-10-21:
- Rebase on master
- Use Module::Load to load Koha::NorwegianPatronDB in non-NL-specific
scripts and modules
- Fix the version number of Digest::SHA
- Fix a missing semicolon in kohastructure.sql
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
It is not necessary for the patron statistics script to pass a colspan
value to the template. The number can be output using Template::Toolkit
syntax.
To test, view the statistics page for a patron. Confirm that the "Total"
cell in the footer spans the correct number of columns. Test with
various numbers of fields in the StatisticsFields system preference.
Followed test plan. Patch behaves as expected.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If you try to create a patron and enter an extended attribute value
which is required to be unique but exists in another record the error
you receive is not clear. It uses the attribute code instead of the
description. This patch adds description to the output.
To test you must have ExtendedPatronAttributes enabled.
- Edit or create an extended patron attribute and designate it a unique
identifier.
- Edit a patron and add a value to that attribute.
- Edit another patron and try to add the same value.
You should get an error which includes both the description of the
attribute you tried to modify and the value you submitted.
Signed-off-by: Christopher Brannon <christopher@debian.brannon.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, no problems found.
Passes tests and Qa script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When duplicating a patron the original patron's library should be
preselected.
To test, apply the patch and choose a patron to duplicate, noting which
library is set as their home library. Click the "Duplicate" button and
cnofirm that the patron's library is preselected on the patron entry
form.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, no problems found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Differences between circ-menu.tt and circ-menu.inc always crop up when a
new menu item is added--usually only to circ-menu.inc as happened with
Bug 9261.
Other sidebar differences are present due to differences in the patron
data passed by various patron-related script to their templates. This
patch also irons out some of these inconsistencies.
To test, apply the patch and check out to a patron whose record has more
than just basic data: othername, country, patron attributes, street
number, road types, etc. View the following pages and compare the patron
data and visible tabs to confirm that they match:
circ/circulation.pl?borrowernumber=X
members/boraccount.pl?borrowernumber=X
members/files.pl?borrowernumber=X
members/mancredit.pl?borrowernumber=X
members/maninvoice.pl?borrowernumber=X
members/member-flags.pl?member=X
members/member-password.pl?member=X
members/moremember.pl?borrowernumber=X
members/notices.pl?borrowernumber=X
members/pay.pl?borrowernumber=X
members/paycollect.pl?borrowernumber=X
members/purchase-suggestions.pl?borrowernumber=X
members/readingrec.pl?borrowernumber=X
members/routing-lists.pl?borrowernumber=X
members/statistics.pl?borrowernumber=X
tools/viewlog.pl?do_it=1&modules=MEMBERS&modules=circulation&src=circ&object=X
The only difference I've found which is not fixed by this patch is the
display of extended patron attributes in the sidebar of moremember.pl.
This is a piecemeal fix for a problem which really deserves a
centralized solution, but at least it gets us back to consistency for
the moment.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Going through all tabs shows consistency is back. A mid term solution should
implement this in a centralized way. Great job Owen!
No koha-qa errors btw.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch just adjusts several POD stuff, and in a few cases
reorganizes a hash definition in order to use spaces instead of tabs
for the QA script to be happy.
Nothing important, really. This patch series just changes '.tmpl' for
'.tt'.
Regards
To+
PS beware that running the koha-qa.pl script can take lots of time on this one
:-D
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>
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 changes the file purchase-suggestions.pl with "suggestionsview => 1" for the template parameter.
In circ-menu.inc i changed the condition from "suggestions" to "suggestionsview" since it seemed to conflict with the existing variable suggestions (and in that case only highlighting the tab when there were suggestions).
Please note that I fixed the troubles with the tab "Fines" in a separate patch 9245.
Test plan:
1) Verify that "Purchase suggestions" does not light up as it should when clicked.
2) Install the patch.
3) Verify that the tab "Purchase suggestions" now actually light up when clicked.
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Works as advertised.
This patch makes shure that mancredit.pl, maninvoice.pl and pay.pl passes the value "finesview=1" that makes the tab active.
Test plan:
1) Go to a library user and the fines tab. Note that the "Fines" tab loses it's highlight when you click "Pay fines", "Create manual invoice" and "Create manual credit".
2) Install the patch.
3) Redo the first step and make shure that the left menu tab "Fines" is now highlighted all the time.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Works as advertised, no regression found on the rest of the tabs.
This patch modifies staff printslip.tt to take into account
caller. Also fixes similar problem on opac printslip.tt
To test:
staff
1. Print hold transfer slip
2. Print transfer slip
3. Print member slip
opac
4. Print self checkout slip
5. Update translation files, check new strings are present
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When a patron has many checked out items, circulation.pl can take a very
long time to load ( on the order of minutes in some cases ). This is
primarily due to the processing of the previous checkouts list. If we
convert to this table to a datatable that fetches its data via ajax, we
can make circulation.pl far more responsive. The same should be done
with relative's checkouts as well.
Test Plan:
1) Apply this patch
2) Observe that the checkouts and relatives' checkouts tables
are now loaded asynchronously
3) Observe and verify the renew and return actions are now
ajax based and function in a manner equivilent to how they
used to.
This bug had quite a few followups, so I squashed all of them into one
change so that code is easier to follow. Original commit messages are below:
Bug 11703 - Use the ajax datatables on patron details page
Bug 11703 - Convert holds tables to ajax datatables
Bug 11703 [QA Followup 1] - Center bProcessing message over table
Bug 11703 [QA Followup 2] - Remove icons from checkout and clear buttons
Bug 11703 [QA Followup 3] - Remove references to UseTablesortForCirc
Bug 11703 [QA Followup 4] - Add back in Today's checkouts/Previous checkouts rows
Bug 11703 [QA Followup 5]
Bug 11703 [QA Followup 6] - Move strings to an include file for translation purposes
Bug 11703 [QA Followup 7] - Fix issues spotted by koha-qa.pl
Bug 11703 [QA Followup 8] - Speed up api/checkouts.pl as much as possible
Bug 11703 [QA Followup 9] - Move scripts from api directory to svc directory
Bug 11703 [QA Followup 10] - Fix errors caused by rebase
Bug 11703 [QA Followup 11] - Prevent multiple fetchs from ajax source
Bug 11703 [QA Followup 12] - Fix problem detected by koha-qa.pl
Bug 11703 [QA Followup 13] - Removed uneccessary data from renewal box during renewal
Bug 11703 [QA Followup 14] - Fix table column span
Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Test plan on bug report:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11703#c98
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
This patch fixes the issues raised in bug 9811 comment 105, 106 and 107:
1/ Add missing space between category and type.
2/ Fix error on searching an empty string (caused by a previous rebase).
3/ Remove sort option on checkbox/borrowernumber column.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
I don't know what is this stuff. I didn't find a call to member.pl with
an orderby parameter.
I am not sure this is in used.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The branches loop was not set with the values.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch add DataTables using server-side processing for the patrons
search.
It adds:
- 1 module C4/Utils/DataTables/Members.pm
- 2 services svc/members/search and svc/members/add_to_list
- 1 template members/tables/members_results.tt
- 1 new practice which is to add template for DataTables in a
subdirectory named 'tables'.
Impacted scripts: members/members-home.pl and members/members.pl
To go further: We can imagine that all patrons searches use the same
service with no big changes: 1 little template creates a JSON file and
to implement DataTables on the template page, that's all.
Amended patch: Since bug 10565 has been pushed, these patches don't
apply cleanly. I had to rewrite a part of the patron list feature.
I removed the choice to add all resultant patrons from a search. I think
this choice is useless with this patch: we are able to display the
number of patrons we want and to select all of them.
Test plan:
- Check that there is no regression on searching patrons.
- Try filters on the left of the screen.
- Try to sort each column.
- Try the "Browse by last name" links.
- Check that the "Clear" button clears yours filters.
- Try with IndependantBranches ON and OFF.
- Verify this feature does not break the patron list feature (cf bug
10565).
Signed-off-by: Cedric Vita <cedric.vita@dracenie.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script, couldn't find any regressions
or problems. Some notes left on the bug.
Bug 9811: Add unit tests for C4::Utils::DT::Members
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Bug 9811: QA followup
- removes 2 tabs
- removes mysqlisms
- add sort on borrowernotes
- fix wrong capitalization
- cat => Category
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Thx for fixing these!
Bug 9811 - multilines notes brakes JSON
In new patron search feature, the search results are fetched using Ajax and returned in JSON format.
The JSON is created by TT using koha-tmpl/intranet-tmpl/prog/en/modules/members/tables/members_results.tt.
One of the fields is the borrower notes. When this notes contains several lines, the JSON is broken.
This patch uses TT fileters to consert in notes linefeeds into HTML line break (html_line_break) and then remove linefeeds (collapse).
Test plan :
- perform a member search that does not return a borrower with a circ note
- edit one of the borrowers returned by this search
- enter serveral lines of text in "Circulation note" and save
- reperform the member search
=> circ note is well displayed on several lines
Bug 9811: use count(primary_key) instead of count(*)
Bug 9811: A limit clause should be always added.
By default, we want to retrieve 20 first results.
Bug 9811: Load the page without any data.
Displaying the first 20 patrons is not useful. With this patch, the
table is hidden and no record is retrieved by default.
On the same way, the existing side effect on redirect disappears.
Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
-------------
-TEST REPORT-
-------------
For the filter: Tested all the search fields, branches, search type.
Found a bug with "date of birth", followup provided.
Tested display limits and verified that AJAX-queries are
efficient (using LIMIT clause) to not stress DB needlessly.
Tested adding Patrons to a list.
A good feature, which seems to work quite well.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Adding my test plan to the last patch of this bug.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This is the same issue as bug 12134, but for the patron deatils page.
Test Plan:
1) Add a manual restriction to a patron and wait until the
expiration date of the restriction has passed. This can be
simulated by modifying borrowers.debarred for a borrower and
setting the date in the past.
2) Go on the detail page for a patron (members/moremember.pl)
3) Note the warning message
"Patron is restricted until XX/XX/XXXX View restrictions"
4) Apply this patch
5) Repeat step 2
6) Note the warning message does not appear anymore
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described, no errors.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
[1] Verify that act of running a guarantor search does not result in
the following warning message in the Apache log:
"guarantor_search.pl: Use of uninitialized value $member in string ne
at guarantor_search.pl line 63"
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
[1] Perform searches for guarantors and verify that there
are no regressions.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The script members/guarantor_search.pl made the following call:
my ($od,$issue,$fines)=GetMemberIssuesAndFines($results->[$i]{'borrowerid'});
Not only does this call always fail because borrowerid is not a valid
key, but the results are never even used in the template!
Test Plan:
1) Apply this patch
2) Verify the gurantor search works as before,
No changes in behavior should be noted
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
buildCGISort can be deleted.
Test plan:
git grep buildCGISort
should return no result.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No more buildCGISort
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Now we can use the method plugin from the memberentry form.
Test plan:
1/ Create a patron and verify sort1 and sort2 dropdown list are
correctly generated.
2/ Select values.
3/ Save.
4/ Edit the patron and verify the selected values are displayed.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Works as described.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Adds support for recording in Koha accountlines a different accounttype
depending on how the fee was paid at the SIP2 station (cash, credit,
etc.)
Adds a new param to recordpayment(), $sip_paytype, which is appended to
the 'Pay' type if present. The payment description is also appended
with " (via SIP2)" if this is present.
In order for other scripts to keep working as expected, "eq 'Pay'"
needed to be replaced with a regex comparison "=~ /^Pay/", so that 'Pay'
and 'Pay-##' would continue to group together.
To test:
1. Make a payment over a SIP2 connection
2. Check the patron record in the staff client; you should see the
modified description
3. Attempt to print a invoice or a reciept for the borrower; the
payment should show up where expected
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds additional informations to the "Print summary"
and the "Print receipt" templates.
Additional information in "Print summary":
* Registration date
* Expiration date
* Library
* Category
* Fines and payments
TEST PLAN
---------
1) Go to a patron.
2) Make sure they have something checked out.
3) Manually add a fine.
4) Under the 'Print' button click 'Print summary'
-- the resulting preview should:
a) have the first for things listed above, and
b) have a new fines and payments section.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
NOTE: The due date of the check out is not part of this patch,
and so I signed off. Similarly, anything required for
slips is configurable elsewhere now and thus comment 1
does not accurately reflect the intent of this patch.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
This works as described and passes all tests and the QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Adds new sub-permissions to updatecharges, 'writeoff' for writing off
fees and 'remaining_permissions' for all other fee related activites.
Test plan:
1) Apply patch
2) Run updatedatabase.pl
3) Remove the 'writeoff' permission from your privileges
4) Attempt to write off a fee, you should not be able to
5) Re-add the 'writeoff' permission
6) Attempt to write off a fee, you should now be able to do so
Signed-off-by: Joel Sasse <jsasse@plumcreeklibrary.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
members/mod_debarment.pl's call to checkauth should pass 'intranet' so
that if the user happens to be logged out they will be redirected to the
staff client login form, rather than the OPAC.
To test, apply the patch and log in to the staff client:
- Add a restriction to a patron's account.
- View the restrictions tab on the patron's account. You should see the
restriction and a "Remove" link for that restriction.
- In another tab, log out of the staff client.
- In the first tab, click the "Remove" link. You should be redirected to
the staff client login page.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Good catch! Works as described, passes all tests and QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch fixes Perl warnings logged when setting up the
patron attribute form in the patron editor.
To test - Patron details entry page:
* Have ExtendedPatronAttributes enabled. Check that "Additional
attributes and identifiers" section behaves.
* Verify that editing and saving a patron record does not
result in the following sorts of entries in the Apache log:
se of uninitialized value $_ in hash element at memberentry.pl line 798
Use of uninitialized value in anonymous hash ({}) at memberentry.pl line 798
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested with different types of patron attributes:
- repeatable
- linked to an authorized value
- free text
Tested editing, adding, removing one of multiple, adding multiple,
etc. No regressions found.
Passes all tests and QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
[1] Template variable actionname is not used in the associated
template. This could be a copy-paste from serials/member-search.pl.
Consequently, the module is no longer needed in member.pl. Template
members/search.tt still contains actionname; it seems that this
emplate is not used too.
[2] $template_name not used in members-home.pl.
Test plan:
[1] Go to Patrons. If you reach that page, you tested members-home.pl
[2] Add a new patron.
[3] Search for a patron. Edit one.
Followed test plan. No problems found.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch modifies CanBookBeRenewed, so that based on
issuingrules.norenewalbefore a new error "too_soon" can be returned.
Also adds a new subroutine GetSoonestRenewDate.
To test:
1) Create an issuing rule with "No renewal before" set to value X
and "Unit" set to days.
2) Test the following steps for both:
Home > Patron > Patron details
Home > Circulation > Checkouts
3) On the checkout page, test for today's issues as well as previous
issues. (Check something out on one day and something else on the
next day, then do the testing.)
4) Confirm that items can't be renewed if current date is more than
X days before due date.
5) Confirm that the date and time of the soonest possible renewal are
displayed in the format specified by global sysprefs "dateformat"
and "TimeFormat".
6) Confirm that items can be renewed if "No renewal before" is
undefined or current date is X or less days before due date.
7) Confirm that if the number of allowed renewals is exceeded
"Not renewable" is displayed, no matter what "No renewal before"
is set to.
8) Test the same things with "Unit" set to hours.
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 refactors the previous code and moves the logic from the pl
to a new routine.
Same test plan as previous patch.
/!\ new unit test filename.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 10861: Reintroduced the cardnumber length check (client side)
Previous patches has removed the pattern attribute of the input, it was
not needed. This patch reintroduces it. It will only work for new
browser version.
Moreover, it manages with the ',XX' format (see UT).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Squashed the last two follow-ups. The pattern test did not work fully for me
in Firefox 26 (very recent). But I see the message when I clear the field.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Some libraries would like to add a check on the cardnumber length.
This patch adds the ability to restrict the cardnumber to a specific
length (strictly equal to XX, or length > XX or min < length < max).
This restriction is checked on inserting/updating a patron or on importing
patrons.
This patch adds:
- 1 new syspref CardnumberLength. 2 formats: a number or a range
(xx,yy).
- 1 new unit test file t/Members/checkcardnumber.t for the
C4::Members::checkcardnumber routine.
Test plan:
1/ Fill the pref CardnumberLength with '5,8'
2/ Create a new patron with an invalid cardnumber (123456789)
3/ Check that you cannot save
4/ With Firebug, replace the pattern attribute value (for the cardnumber
input) with ".{5,10}"
5/ You are allowed to save but an error occurred.
6/ Try the same steps for update.
7/ Go to the import borrowers tool.
8/ Play with the import borrowers tool. We must test add/update patrons
and the "record matching" field (cardnumber or a uniq patron attribute)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested adding, updating; importing and ran unit test.
Preliminary QA comments on Bugzilla
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch removes some dead code concerning the handling of patrons
that are members of other, institutional patrons. This code did not
work; removing it clears the field if somebody wants to do a better
implementation of such relationships between patrons.
This patch:
[1] Removes the memberofinstitution system preference.
[2] Removes the following routines:
C4::Members::get_institutions()
C4::Members::add_member_orgs() (and removing this routine
removes a reference to a borrowers_to_borrowers table that
does not exist).
There should be no changes whatsoever to system functionality with this
patch (with the trivial exception of the absence of the
memberofinstitution system preference).
Test plan:
[1] Look at the code and use grep, git grep, etc. verify this patch
does not remove something in use.
[2] Verify that there are no regressions upon adding or editing
a patron record.
[3] Verify that the memberofinstitution system preference has been
removed
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch corrects some errors with the staff client's patron purchase
suggestions page (members/purchase-suggestions.pl).
To test, apply the patch and make sure the patronimages system
preference is enabled.
- View the purchase suggestions page for a patron whose record has a
patron image attached. The image should appear in the left-hand
sidebar.
- View the page for a patron who has submitted no purchase suggestions.
The message should be styled correctly.
- The toolbar on the page should look correct and work correctly.
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Currently road types are stored in a specific table in DB. Moreover, an
admin page is present in order to manage them.
This patch proposes to remove this table and this page in favour of a
new authorised value category 'ROADTYPE'.
This patch:
- adds a new AV category 'ROADTYPE' (created from the roadtype table
content).
- remove the roadtype table.
- remove the .pl and .tt file admin/roadtype
- remove the 2 routines C4::Members::GetRoadTypes and
C4::Members::GetRoadTypeDetails
Test plan:
1/ Execute the updatedatabase entry and verify existing roadtypes are
now stored in the AV 'ROADTYPE'.
2/ Verify you can add/update a streettype for patrons.
3/ Verify on following pages the streettype is displayed in patron
information (top left):
circ/circulation.pl
members/memberentry.pl
members/moremember.pl
members/routing-lists.pl
Signed-off-by: Sophie Meynieux <sophie.meynieux@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This script is no longer used, and in addition has problematic
handling of its parameters that could lead to writing to
arbitrary files on the server.
To test:
[1] Verify that member-picupload.pl is no longer referred
to in the codebase after applying this patch.
[2] Verify that there are no regressions in patron
photo management.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Found no regressions in removing this script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds the renewal count to the 'Check out' and "Details' tabs
of the patron record.
This information already exists in the OPAC view of the patron record.
Since librarians might be serving patrons in person who want to know
this information without looking it up online, it makes sense to show
it in the staff client.
There may also be times where librarians want to see how many renewals
a patron has left, how many they've used already, etc. when making other
decisions.
_TEST PLAN_
Before applying:
1) Go to "Check out" with a patron that has some check outs before today
2) Add some check outs for today
*Ensure that all issues are for items that can be renewed*
3) Note that the Renew column just says '0' followed by a check box
4) Check the 'Detail' tab. It should say the same.
Apply the patch.
5) View the "Details" and "Check out" tabs again
6) Note that the renewal count now appears in the form resembling:
5 of 5 renewals remaining
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
All tests pass
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The method of checking the logged in user for superlibrarian privileges
is obtuse ( $userenv && $userenv->{flags} % 2 != 1 ) to say the least.
The codebase is littered with these lines, with no explanation given. It
would be much better if we had one subroutine that returned a boolean
value to tell us if the logged in user is a superlibrarian or not.
Test Plan:
1) Apply this patch
2) Verify superlibrarian behavior remains unchanged
Signed-off-by: Joel Sasse <jsasse@plumcreeklibrary.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Comments on second patch.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch fixes a bug where using the patron editor to add a new
restriction overwrote the first existing one.
Test Plan:
1) Edit a patron, add a restriction
2) Edit the patron again, add a second restriction
3) Note the first restriction has disappeared!
4) Apply this patch
5) Edit the patron again, add another restriction
6) Note the previous restriction is not longer removed
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested:
- Adding and removing multiple restrictions from
- the details tab
- the checkouts tab
- the edit patron form
All works as expected.
Patch passes all tests in t, xt, and QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
ModMember supposes the password given in parameter is the
password string, so if it receives the encrypted password,
it will encrypt it again! By simply deleting the password key
from the hash, ModMember leaves the password unchanged.
Test plan:
1/ Create or choose a child patron
2/ Update it to an adult category using the
"Update child to adult patron" link
3/ Try to log in at the OPAC with this patron: It is not
possible, the password has changed
4/ Apply the patch and try again previous steps
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Confirmed the problem and tested the patch fixes it.
Passes all tests and QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch makes the message that is displayed when attempting to
view circ history for the anonymous patron more informative. It
also removes a potential source of log noise if the AnonymousPatron
system preference happens to be set to a blank value.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When using an anonymous patron to anonymise issues history, this patron
may have a huge number of old issues. In this case, trying to display
the reading history of this patron will perform a huge SQL query.
It is not useful to have the reading history of this anonymous patron.
This patch adds an alert instead of old issues when displaying reading
records of anonymous patron.
Test plan :
- Set syspref AnonymousPatron to 0.
- Select a borrower with old issues. For example 123.
- Look at its reading records page : members/readingrec.pl
=> Old issues are displayed in a datatable
- Set syspref AnonymousPatron with this borrower number. For example 123.
- Look at its reading records page
=> Old issues are not displayed and an alert is displayed
- Using SQL query, remove old issues of this borrower :
DELETE FROM old_issues WHERE borrowernumber=123.
- Look at its reading records page
=> A message is displayed
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
This works as advertised and seems like a reasonable thing to do. I
suspect that someone will object... Perhaps that person will implement a
solution which uses an AJAX DataTable.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test plan:
1/ edit a patron
2/ set a sms alert number
3/ save
4/ edit the patron
5/ set the sms alert number to a blank value
6/ save
7/ the sms number is now an empty string
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Test plan used:
- Activate the SMS functionality by giving a 'fake'
SMSSendDriver of TEST
- Activate EnhancedMessagingPreferences
- Create a new patron, set Other phone to 'test'
- Notice that Other phone was copied to sms number
- Edit messaging preference section using the edit link
below on the details tab and delete SMS number
- Verify it's not possible to unset the SMS number
- Apply patch
- Repeat deleting - this time it works
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch:
- changes the GPL version from 2 to 3.
- uses the datatables.inc file
- removes the single pixel before and after the DT (modifying the sDom
value).
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds a new tab to the patron side menu for purchase
suggestions. From this new tab, a librarian can view the patron's
existing purchase suggestios and also create new suggestions in the
name of that patron.
Test Plan:
1) Apply patch
2) Ensure the system preference 'suggestions' is enabled
3) View the details for a patron
4) Click the new 'Purchase suggestions' tab
5) Click the 'New purchase suggestion' button
6) Add the new purchase suggestions
7) You should now end up back at the borrower's purchase suggestions
8) Verify the new purchase suggestion was added
Signed-off-by: Corey Fuimaono <agent.075@gmail.com>
Step though the test plan. All OK.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
1/ Edit a patron
2/ Add a restriction with a date (in any format other than iso)
3/ Note the date is not saved
4/ Apply patch
5/ Add restriction again, note it is saved
The problem is output_pref was being called with the wrong parameters
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Note: The issue in on the memberentry form only (not the restriction
form on the check out page).
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.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>
When printing a payment receipt, the payment did not display, only the
total currently owed.
Test Plan:
1) Create a payment for a borrower
2) Print the payment with the "print" button to the right of the payment
3) Note the missing payment line
4) Apply this patch
5) Repeat step 2
6) Note the payment line now displays
Signed-off-by: cedric.vita@dracenie.com <cedric.vita@dracenie.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Koha::DateUtils::output_pref took 4 parameters and the last one is a
boolean, so some calls were:
output_pref($dt, undef, undef, 1)
This patch changes its prototype to
output_pref({
dt => $dt,
dateformat => $dateformat,
timeformat => $timeformat,
dateonly => $boolean
});
An alternative is to call the output_pref routine with a datetime
object, without using an hashref:
output_pref($dt);
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>
The patron lists feature is somewhat similar to the record lists feature
in that it allows a librarian to create a list of patrons for later
retrieval and manipluation. These lists can then be used with the batch
patron modification tool.
Test Plan:
0) Apply the patch for Bug 8798
1) Apply this patch
2) Run updatedatabase.pl
3) Access the patron lists feature from Koha's Tools menu.
4) Create a new list via the "New patron list" button.
5) For this list, click the "Edit" button, and change the list name.
6) For this list, click the "Add patrons" button, and search for and
add some patrons to your list.
7) For this list select some patrons to remove them.
8) Try both adding some new patrons, and removing some old patrons
as a single action.
9) Click the "Patrons" link on the Koha toolbar
10) Search the patrons, or browse by letter to get patron results
11) Check the checkboxes next to one or more patrons, and add the
selected patrons to your existing list.
12) Change the "Selected patrons" pulldown to "All resultant patrons"
and add them to your list.
13) Check the checkboxes next to one or more patrons, and add the
selected patrons to a new list.
14) Try manipulating a list of patrons using the batch patron
modification tool.
15) Go back to the Patron Lists feature and delete your lists.
16) Run 'prove t/db_dependent/PatronLists.t'
Signed-off-by: Nora Blake <nblake@masslibsystem.org>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Enable patronimages
4) Verify patron images are still displaying correctly
5) Test deleting a patron image
6) Test adding a patron image from moremember.pl
7) Test adding a patron image from tools/picture-upload.pl
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The move avoids a problem where many modules would gain
a dependency on C4::Auth just because C4::Members needs access
to hash_password().
This patch also adds a couple unit tests for the new password
hashing code.
To test:
[1] Verify that there are no regressions on the test plan for bug
9611.
[2] Verify that t/AuthUtils.t and t/db_dependent/Auth.t pass.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
What this patch aims to accomplish?
* All new passwords are stored as Bcrypt-hashes
* For password verification:
- If the user was created before this patch was applied then use
MD5 to hash the entered password <-- backwards compatibility
- If the user was created after this patch was applied then use
Bcrypt to hash the entered password
* Any password change made via the staff interface or the OPAC will
be automatically Bcrypt-hashed; this applies to old users whose
passwords were stored as MD5 hashes previously
Test plan:
1) Add new users and check whether their passwords are stored as
Bcrypt hashes or not.
2) To test that authentication works for both old as well as new
users:
a) Login as an existing user whose password is stored as a
MD5 hash
b) Login as an existing user whose password is stored as a
Bcrypt hash
3) In the staff interface, change the password of an existing user
whose password is stored as an MD5 hash
a) Check the new password is stored as a Bcrypt-hash in the database
b) Try to login with the new password
4) In the OPAC, verify that
a) Old user with old pass can change password, new format
b) New user with new pass can change password
c) Old and new user with self-updated pass can login
Whitespace cleanup was contributed by Bernardo Gonzalez Kriegel.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
[1] In the staff interface, enter nothing in the patron search box
and hit the search button.
[2] Note the errors in the logs concerning an uninitialized $count
variable.
[3] Apply the patch and repeat step 1. Note that this time, no
warnings are logged.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test
1/ Uncomment the use warnings line
2/ Search for a patron, notice all the warnings
3/ Browse for a patron, notice warnings
4/ Apply patch
5/ Repeat 3 and 4
6/ Notice no errors and the search still works
This depends on the patch for Bug 10835
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests, no regressions found.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Previously printing a fine invoice would result in a page with both the
single item charge and the total outstanding amount. Right now only the
total outstanding is printed.
Test Plan:
1) Print a fine, note the fine doesn't show, only the total
2) Apply patch
3) Print a fine, not the fine does show
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The patron search type option "contains" works fine for multiple
strings, but returns no results for a single string search. For example,
the patron "Henry Acevedo" will be returned for a "contains" search
"en ev" but not for just "en" or "ev".
Test Plan:
1) Create 2 patrons named "Test One" and "Test Two"
2) Run a "contains" search for the term "est"
3) Note no results were found
4) Apply this patch
5) Repeat step 2
6) Note the patrons now display in the search results.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass.
Also checked that 'starts with' still works as expected -
searching for ev will only return "Eva Dillon" from the
example patrons in this case.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds subtitles (from Keyword to MARC mapping) to the
following tables on the checkout page:
- Checkouts
- Previous checkouts
- Relative's checkouts
- Relative's previous checkouts
- Holds
Additionally it suppresses the appearence of the superfluous word "by"
in cases where the biblio has no author.
Test scenario:
--------------
1)
Make sure that you have one or more fields mapped to subtitle in:
Home . Administration . Keyword to MARC mapping
(e.g. 245 b)
2)
Test the checkout page with patrons having
- current checkouts (today)
- previous checkouts
- relatives (e.g. kids) with current /previous checkouts
- holds on items
- holds on biblios
...with items having:
- title, subtitle, author
- title, no subtitle, author
- title, subtitle, no author
- title, no subtitle, no author
3)
Do the same on patron's detail page
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
All tests pass
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
- Place a hold request for a patron
- From the patron details page, navigate to the holds table,
then cancel (delete) it.
- Verify that the hold request is gone.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
If a warning about a duplicated patron attribute is returned,
the value was being passed back for display in the warning
message with the same name as the variable in errors
As the message is displayed in the context of errors
the error value 1 was being displayed not the value
duplicated as intended.
Pass the value to the template with a unique name.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I fixed another tiny typo while signing off: "is already in use" instead
of "is already is use."
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passes koha-qa.pl, works as advertised.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When viewing the list of a patron's holds on the circulation page or the
patron detail page the table of holds doesn't display the holds
expiration date, if present. This patch adds display of the hold
expiration date.
To test, place a hold for a patron and set an expiration date for it.
View the patron's existing holds on both circulation.pl and
moremember.pl. The expiration date you chose should appear in the table
of information about existing holds.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
works great
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
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>
Test Plan:
1) Enable IndependantBranches
2) Apply this patch
3) Run updatedatabase.pl
4) Verify that the system preference still functions correctly
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Code will also respect notes when using the "Writeoff All" button but WILL NOT when using either the "Pay Amount" or "Pay Selected" buttons Fixed uri encoding of arguments
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.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
- Remove "all" occurrences (those I found!) of dateformat_*
From now the only way to get the date format is a string comparaison
(dateformat == "metric")
Checked with the command:
git grep "\(dateformat_us\|dateformat_metric\|dateformat_iso\)" | grep
-v translator
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Tested all the datepickers I could find, looks good.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Some files have the old 59 Temple address instead of the 51 Franklin
street.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I see lots more which will need to be corrected as well.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Corrects addresses in 3 files.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
When the patron detail page switched to DataTables no accommodation was
made for metric date formats in sorting.
This patch adds sorting based on data in a span's title attribute, and
thus requires that the patch for Bug 9887 be applied.
To test, view the detail page for a patron who has assorted checkouts,
relatives' checkouts, and holds. Sorting of date columns should be
correct with the dateformat preference set to any value.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass.
Nice improvement.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
In current implementation (mostly commented out in this patch)
uses heuristic to guess which strings need decoding from utf-8
to binary representation and doesn't support utf-8 characters
in templates and has problems with utf-8 data from database.
With this changes, Koha perl code always uses utf-8 encoding
correctly. All incomming data from database is allready
correctly marked as utf-8, and decoding of utf8 is required
only from Zebra and XSLT transfers which don't set utf-8 flag
correctly.
For output, standard perl :encoding(utf8) handler is used
so it also removes various "wide character" warnings as side-effect.
Test scenario:
1. make sure that you have utf-8 characters in your biblio
records, patrons, categories etc.
2. try to search records on intranet and opac which contain
utf-8 characters
3. install language which has utf-8 characters, e.g. uk-UA
dpavlin@koha-dev:/srv/koha/misc/translator(bug_6554) $
PERL5LIB=/srv/koha/ perl translate install uk-UA
4. switch language to uk-UA and verify that templates
display correctly
5. test search and Z39.50 search and verify that caracters
are correct
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I followed the test plan, adding utf-8 characters to library names,
patron categories, titles, and authorized values. I tried the uk-UA
translation and everything looked good.
When performing Z39.50 searches for titles containing utf-8 characters I
got results which were still occasionally contaminated with dummy
characters [?] but I assume this is Z39.50's fault not the patch's.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Already signed, add mine.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
The routing list tab displays on patron pages even if the RoutingSerials
preference is OFF. Display of the tab should be conditional on that pref
being turned on.
This patch adds a check for the RoutingSerials preference to the menu
include files and amends the affected scripts to make the variable
available on the pages where those includes are used.
To test, view the following pages with RoutingSerials both on and off.
The routing list tab should be shown and hidden accordingly:
- Circulation
- Patron details
- Patron fines
- Pay fines
- Pay amount/selected (click from the Pay fines page)
- Create manual invoice
- Create manual credit
- Patron circulation history
- Patron modification log
- Patron notices
- Patron routing lists
- Patron statistics
- Patron files
- Patron permissions
- Set patron password
- "Can't delete patron" page (try to delete a patron with checkouts).
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Touches a lot of files, but only a tiny change in each, works well.
Could perhaps be set in C4/Auth instead, but that's no reason not to
sign off
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
When modifying a patron through different pages, the userid
generation does not behave always the same way; this patch
corrects this:
- when firstname and surname are present in the form, they
are used for the generation;
- if there are not in the form, the firstname and surname
in database are used instead.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Work as described. No errors.
Test
This patch lacks a test plan, so I do the following
1) New user, empty userid, autocompleted
2) Edit user, change userid, saved correctly
3) Edit user, main edit window, emptied userid, autocompleted
4) Edit user, Detail > Library use, emptied userid, not autocomplete (not even a dot)
5) Applied patch
6) Repeated 1-3, same behavior
7) Repeated 4), now autocompletes with same userid as 3)
So, works as described.
No koha-qa errors.
NOTE: It's impossible now to delete userid from interface.
Off-topic: tried an userid in Arabic, works very well.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
When renewing a patron from the patron details page, ensure that
the "Patron's account has been renewed until XXX" is actually
displayed.
This patch introduces a was_renewed CGI and template parameter
to clarify the intent of the relevent template sections.
To test:
- Before applying the patch, renew a patron from the patron
details page and verify that you don't see the renewal confirmation.
- After applying the patch, renew the patron from the details page
and verify that the "Patron's account has been renewed until XXX"
message shows up.
- Renew the patron from the checkout page and verify that the confirmation
message shows up.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Message now displays for both tabs.
Fixed tab to make QA script pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
When OpacMaintenance is on, any opac page will redirect to maintenance.pl.
Some pages of intranet have the same behavior and you get 404 error.
This is because in checkauth, if type arg is undefined it is "opac" by default.
This patch adds type arg in all intranet calls of checkauth.
Test plan :
- Set syspref OpacMaintenance=Show
- Go to a borrower page
- Click on "Fines" and "Create manual invoice"
- Enter an amount and save
=> Check you go to members/boraccount.pl and not maintenance.pl with 404 error
OK
- Click on "Fines" and "Create manual credit"
- Enter an amount and save
=> Check you go to members/boraccount.pl and not maintenance.pl with 404 error
OK
- Edit borrower
- Set "Restricted" to yes and save
- Click on "Lift restriction" in messages
=> Check you keep in member page and not maintenance.pl with 404 error
OK
- Edit borrower
- Set "Expiry date" to a day in the past and save
- Click on "Renew" in messages
=> Check you keep in member page and not maintenance.pl with 404 error
OK
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Good catch, a tricky bug.
http://bugs.koha-community.org/show_bug.cgi?id=9952
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Removed a few tabs from mancredit.
All tests and QA script pass now.
Good test plan.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch corrects several uninitialized value errors.
Test plan:
- Edit a borrower
- Enter a surname using lowercase (it will be displayed uppercase by CSS) and save
=> Borrower surname is uppercase
- Edit an organisation (depends on borrower category)
- Enter a surname using lowercase (it will be displayed uppercase by CSS) and save
=> Borrower surname is uppercase
- Go to a borrower page who has today issues
- Click on More/Export today's checked in barcodes
=> You get a file to dowload
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This follow up reinstates or add check for undef returned
by C4::Context->userenv, only where previous patch touch
code.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch replace use of CGI::scroll_list() to show list of branches.
In two files, marc21_linking_section.pl and unimarc_field_4XX.pl,
the scrolling list is created but not used in the template file,
so the code is removed.
Also minor renaming/normalizing of variables.
To test:
1) Install with some branches, records and patrons
2.1) Select a record, click 'Place hold', select user,
there is a library pull-down next to 'Pickup at:',
list is ordered case sensitive
2.2) Go to Reports > Average loan time,
next to Library is a pull-down,
list without order
2.3) Go to Reports > Catalog by item type,
next to 'Select a library' is a pull-down,
list is ordered case sensitive
2.4) This is tricky, go to Reports home,
change last part of URL 'reports-home.pl' with
'manager.pl?report_name=issues_by_borrower_category'
(can't find a direct link), next to 'Select a library'
is a library pull-down,
list without order
2.5) Edit/Add a patron, on section 'Library management'
there is a library pull-down, case sensitive
2.6) OPAC, as logged user, make a suggestion or hold,
there is library pull-down, correct order
3) Apply the patch
4.1) Repeat 2.1), correctly ordered list
4.2) Repeat 2.2), correctly ordered list
4.3) Repeat 2.3), correctly ordered list
4.4) Repeat 2.4), correctly ordered list
4.5) This is a bit more work
There are 3 possible situations to test:
A) No branches, must show a message that are no
libraries defined
B) New patron, must show a correctly ordered
list of branches, current branch selected
C) Edit patron, must show a correctly ordered
list of branches, patron branch selected
4.6) Small changes on variable names, so retest 2.6)
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.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>
Currently, if $ENV{DEBUG} is set (for example to 1), the debug level
will be printed on the Add/Edit Patron pages (memberentrygen.tt) in the
form of: "Debug is on (level 1)".
While many if not most folks might not set $ENV{DEBUG} on a production
system, there is no reason to have this information printing on the
member template(s).
No where else in Koha is there a template that prints $ENV{DEBUG}
information, with the exception of calendar.inc, although that doesn't
activate until at least debug level 2 or 5, so it might be worth holding
on to. It is certainly more complicated than simply printing the debug
level. I don't do development on the calendars, so I'm not going to
address that one.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Elliott Davis <elliott@bywatersolions.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
The subroutines writeoff() and get_writeoff_sth() (and the two package
variables $writeoff_sth and $add_writeoff_sth) defined in members/pay.pl
are not used at all.
To test:
1) View members/pay.pl by looking at the record of a patron who has
at least seven fines/fees and clicking the "Pay fines" tab after
clicking the "Fines" tab on the left side
2) Write off a single item in the table on members/pay.pl using the
button labelled "Write off"
3) Pay a single fine by clicking the "Pay" button
4) Pay a portion of a fine by selecting a checkbox on one of the lines
in the table and clicking the "Pay amount" button
5) Select two lines in the table and click the "Pay selected" button
6) Write off all remaining fines
If all your actions show up in the table on the Account tab, this patch
works.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Test Plan:
1) Write off fines as various branches
2) Observe the stats lines include the wrong branchcode
3) Apply patch
4) Repeate step 1
5) Observe the stats lines include the correct branchcode
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Also tested by changing branch and writing off again - all
tests pass.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Checked individual and complete write off for different branches.
Write offs were always recorded correctly for the logged in branch.
All tests and QA script pas.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
For a duplicated patron, the "Saluation" information
is now empty by default.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
If a patron lives at 4345 Library Rd, a search on Street Address for
Library should find it. However, it does not, but a search for 4345
Library does. This patch adds a "Search Type" drop-down, defaulting
to the current behaviour.
To test:
1) Search for a patron based on a non-leading part of a field.
2) Should return no results.
3) Search again with "Search Type" of "Contains".
4) Should return the patron.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.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>
Moving text of an error message from the script into the
template. To test, submit an amount which is greater
than the amount due. You should see an error message
displayed correctly with a properly-formatted currency
amount.
Signed-off-by: Marc Veron <veron@veron.ch>
Patch behaves as expected.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
The staff client has two almost identical include files which
can be consolidated: circ-toolbar.inc and members-toolbar.inc.
This patch marges the slight differences between them and
eliminates circ-toolbar.inc, that being the one which was used
on fewer pages.
In order to accommodate the different "destination" variable
for operations which redirect back either to circ or patrons,
circulation.pl defines "destination" in the template.
Revision corrects a redirect error in setstatus.pl which
predates this patch but which never showed up until now.
To test, perform various operations from the toolbar on at least
two pages: circulation.pl and moremember.pl.
Operations: Edit, add child, duplicate, change password, print (all
options), search to hold, renew, set permissions, delete, update child
to adult, and export checked-in barcodes. In most cases simply
confirming that the link takes you to the right place is enough.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
- Adding simple style to register link on home page
- Adding unique ids to new pages and to blocks containing
registration links
- Adding better page titles and breadcrumb links to some pages
- Correcting bug which meant incorrect message showed on registration
page when OPACPatronDetails preferences is turned off
- Passing patron details to opac-memberentry.tt so that patron's
name can be displayed in breadcrumbs
- Improving display in staff client of patron record updates
waiting to be approved.
- Adding a sort by name to output of pending patron record updates
- Adding updated JqueryUI library files to include expanded widget
options.
The changes in this patch require the addition of the jQueryUI
Accordion widget. Other pending patches are seeking to add
enough of the other remaining missing widgets that it seems time
to go ahead and add the rest.
Future submissions which add usage of these widgets will have
to be careful to make changes to Koha's CSS where necessary.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passed-QA-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>
In a librairies network, we would like to declare specific values just
for one (or more) library.
Here we implement the ability to associate categories, patron attributes
types and/or authorised_values with librairies (branches).
This patch adds 3 new association tables:
- categories_branches ( association table between categories and branches )
- authorised_values_branches ( association table between
authorised_values and branches )
- borrower_attribute_types_branches (association table between
borrower_attribute_types and branches )
Plan test:
- Create (or modify) categories, patron attributes and
authorised_values and link it with one (or more) library.
- Set one of these librairies
- Go to one of the multiple pages where this specific value must be displayed
and check that it does appear.
- Set a library not concerned.
- Check on the same pages this value is doest not appear.
A page list:
cataloguing/addbiblio.pl
cataloguing/additems.pl
members/members-home.pl
members/memberentry.pl
acqui/neworderempty.pl
tools/modborrowers.pl
and others :)
Please say me if filters don't work on some pages.
Signed-off-by: Delaye Stephane <stephane.delaye@biblibre.com>
Signed-off-by: Koha Team Lyon 3 <koha@univ-lyon3.fr>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Melia Meggs <melia@bywatersolutions.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
