Re: [Koha] Adding items to a list not possible in Koha 21.11.09
Another tip for troubleshooting in case you haven't tried it - Bug 14004 added the ability to disable both custom CSS and JS by appending some parameters to your staff client's URL. This would let you load these pages without also loading your library's custom CSS and JavaScript, so that you can more definitively rule out that it isn't a local issue. You'd add ?DISABLE_SYSPREF_IntranetUserJS=1_SYSPREF_IntranetUserCSS=1 to the end of your URL. For example, if your staff client is accessed at http://www.mylibraryisthebest.com, you'd load http://www.mylibraryisthebest.com/?DISABLE_SYSPREF_IntranetUserJS=1_SYSPREF_IntranetUserCSS=1 so that it does not load your CSS and JS. Just a thought for some further troubleshooting. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14004 Arturo Longoria Reference Librarian/Web Administrator Texas State Law Library www.sll.texas.gov -Original Message- From: Koha On Behalf Of Michael Kuhn Sent: Wednesday, July 27, 2022 3:04 AM To: gvera...@dataly.gr; 'Andreas Roussos' ; 'Koha' Subject: Re: [Koha] Adding items to a list not possible in Koha 21.11.09 Hi George > Could you please share some screenshots ? to give me a try to > replicate > that ? 1. Perform a search and check an item on the first page * https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fadminkuhn.ch%2Fdownload%2Flist-1.pngdata=05%7C01%7Carturo.longoria%40sll.texas.gov%7C8191ef6467b446af61cd08da6fa6a4f3%7Caefc2264480e4d03937744890fe44e40%7C0%7C0%7C637945058803013164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=CnM2Pdg6tyvTEwiymXm6hrJwB4YTvMe5B7VnE1taWWU%3Dreserved=0 2. Click on "Add to list" and select a list, the message "No item was selected" appears * https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fadminkuhn.ch%2Fdownload%2Flist-2.pngdata=05%7C01%7Carturo.longoria%40sll.texas.gov%7C8191ef6467b446af61cd08da6fa6a4f3%7Caefc2264480e4d03937744890fe44e40%7C0%7C0%7C637945058803013164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=H3Yjq1b6ERiMixk8qBxrLJiHMjb3eSB6PWFaUiX2q%2F0%3Dreserved=0 Best wishes: Michael -- Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz T 0041 (0)61 261 55 61 · E m...@adminkuhn.ch · W https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.adminkuhn.ch%2Fdata=05%7C01%7Carturo.longoria%40sll.texas.gov%7C8191ef6467b446af61cd08da6fa6a4f3%7Caefc2264480e4d03937744890fe44e40%7C0%7C0%7C637945058803013164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=9m17Dgx9Rts549tixnuh%2FDjJQmWNrWYopxRVqfXaHzw%3Dreserved=0 > -Original Message- > From: Michael Kuhn > Sent: Wednesday, July 27, 2022 10:34 AM > To: gvera...@dataly.gr; 'Andreas Roussos' ; 'Koha' > > Subject: Re: [Koha] Adding items to a list not possible in Koha 21.11.09 > > Hi George > > > Do you try to add items by barcode or by itemnumber ? > > I search for anything that gives me a result list. > > In this list (on the first page) I check one ore more items on the left side, > then try to add it/them to an existing list. But Koha says "No item was > selected" and doesn't add the item(s) to the list. > > Best wishes: Michael > -- > Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis > Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz T 0041 (0)61 > 261 55 61 · E m...@adminkuhn.ch · W > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.adminkuhn.ch%2Fdata=05%7C01%7Carturo.longoria%40sll.texas.gov%7C8191ef6467b446af61cd08da6fa6a4f3%7Caefc2264480e4d03937744890fe44e40%7C0%7C0%7C637945058803013164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=9m17Dgx9Rts549tixnuh%2FDjJQmWNrWYopxRVqfXaHzw%3Dreserved=0 > > > >> Do you try to add items by barcode or by itemnumber ? >> >> Best Regards, >> George Veranis >> >> -Original Message- >> From: Koha On Behalf Of Michael Kuhn >> Sent: Tuesday, July 26, 2022 7:32 PM >> To: Andreas Roussos ; Koha >> Subject: Re: [Koha] Adding items to a list not possible in Koha 21.11.09 >> >> Hello Andreas >> >>> Thank you very much for taking the time to provide these details! >>> >>> I'm interested in finding what's causing this misbehaviour, so > >> please bear with me as I bombard you with more questions! ;-) > > Have you >> made any staff interface customisations with JavaScript > or jQuery? Is >> there anything in your instance's
Re: [Koha] SIP, Envisionware's PC Reservation, and failed login attempts
Thanks for the link, Kyle! Yes, that’s exactly what’s happening here and what I suspected because PC Reservation does not require the Koha password in order to create a session, so I figured Koha was reacting to that and counting it as a failed login attempt. But yes, despite the note in the bug, I can confirm that is happening on our instance that is using 18.11.10. I tested it this morning several times. From: Kyle Hall Sent: Tuesday, October 29, 2019 11:44 To: Arturo Longoria Cc: koha@lists.katipo.co.nz Subject: Re: [Koha] SIP, Envisionware's PC Reservation, and failed login attempts That shouldn't be happening on 18.11.10, here is the relevant bug: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21997 Kyle --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Tue, Oct 29, 2019 at 12:26 PM Arturo Longoria mailto:arturo.longo...@sll.texas.gov>> wrote: Hi all, I've stumbled upon an issue with my library's setup involving Koha 18.11.10 and Envisionware's PC Reservation, but I'm not sure if it's a bug or a misconfiguration on our part. If anyone has any tips or feedback, I'd really appreciate it! We use SIP to authenticate patrons who wish to create a computer session via PC Reservation. We also have the Koha FailedLoginAttempts preference set so that an account is locked after X failed login attempts. But I'm noticing that the borrowers.login_attempts field is increased by 1 each time a user logs on to our public computers even if the login is successful on the first attempt. That is, when I create a computer session successfully, the login_attempts count in the borrowers table is increased regardless. I noticed this after doing maintenance on several computers that required me to log in via PC Reservation. When I went to log in to the staff client later, my account had been locked out. Has anyone else experienced this? Arturo Longoria Web Administrator Texas State Law Library www.sll.texas.gov<http://www.sll.texas.gov> ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz> https://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] SIP, Envisionware's PC Reservation, and failed login attempts
Hi all, I've stumbled upon an issue with my library's setup involving Koha 18.11.10 and Envisionware's PC Reservation, but I'm not sure if it's a bug or a misconfiguration on our part. If anyone has any tips or feedback, I'd really appreciate it! We use SIP to authenticate patrons who wish to create a computer session via PC Reservation. We also have the Koha FailedLoginAttempts preference set so that an account is locked after X failed login attempts. But I'm noticing that the borrowers.login_attempts field is increased by 1 each time a user logs on to our public computers even if the login is successful on the first attempt. That is, when I create a computer session successfully, the login_attempts count in the borrowers table is increased regardless. I noticed this after doing maintenance on several computers that required me to log in via PC Reservation. When I went to log in to the staff client later, my account had been locked out. Has anyone else experienced this? Arturo Longoria Web Administrator Texas State Law Library www.sll.texas.gov ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Koha/Zebra record lengths
Hi Paul, Our library also ran into this issue with really large bib records for long-running periodicals. This was back in 2017, and this bug was filed where the issue was discussed: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15399 If I remember correctly, it seems that there may be some ways to fine-tune your Koha settings to allow for indexing records that are larger than the ~1MB size limit, but doing so breaks the ability to run your Koha as a Z39.50 server. The discussion in the bug I linked to explains this more. So, for our library, since we are set up to use Z39.50, it was a no-go. We opted instead to break up our huge bib records into more manageable records that don't bump up against the size limit. So, our long-running periodical records are now broken up by decades/time periods and we use the MARC 780/785 fields to indicate the previous/next record in the series, like so: https://catalog.sll.texas.gov/cgi-bin/koha/opac-detail.pl?biblionumber=385 I hope this helps. Arturo Longoria Reference Librarian/Web Manager Texas State Law Library www.sll.texas.gov -Original Message- From: Koha On Behalf Of Paul A Sent: Thursday, August 22, 2019 10:21 To: koha@lists.katipo.co.nz Subject: [Koha] Koha/Zebra record lengths We've lost a record (opac and staff) biblio + 422 items. It's there in all its glory in MySQL, but Zebra won't show it. The Koha wiki mentions: "Record length of 101459 is larger than the MARC spec allows (9 bytes) -- This will show up if you are trying to index a record that has a large number of items (common with serials, for example), or just has a lot of text in the record itself. /.../ Koha can do the indexing by using the MARCXML format rather than ISO 2709, and this gets around the problem. If you add '-x' to the reindex_zebra.pl command when indexing biblios, it will do this" We always have used '-x' for biblios (did it again a couple of minutes ago.) No joy I can (I hope!) just delete the last item (or two or three) from MySQL and reindex, but before I go there, does anyone have previous experience with this problem? Many thanks --Paul ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] double fines
I thought I'd provide an update on this. We had a patron return 5 items today that had entered Long Overdue (Lost) status via our long overdue cron job. These had already accrued their max fines. We wanted to test the behavior of CalculateFinesOnReturn, which we had set to "Do". Upon checking in the first item, yes, the fines were doubled up on a new line item -- *not* the behavior we want. I switched CalculateFinesOnReturn to "Don't", checked in another item, and this time there was no doubled-up fine -- the behavior we *do* want! I toggled a couple more times and the behavior was the same. We have switched CalculateFinesOnReturn to "Don't" and will continue monitoring to see if there are any unexpected changes. Arturo Longoria Reference Librarian/Web Manager Texas State Law Library www.sll.texas.gov -----Original Message- From: Arturo Longoria Sent: Wednesday, April 17, 2019 15:37 To: Margo Duncan ; Renvoize, Martin ; Koha Subject: RE: [Koha] double fines Our library is still on 18.05.10, so I'm not sure it's specific to 18.11, unfortunately. A new related bug has been filed here, https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22727, but that doesn't seem to capture what's happening at our library because our WhenLostForgiveFine preference is set to "Don't Forgive," not "Forgive" as the bug description indicates. Arturo Longoria Reference Librarian/Web Manager Texas State Law Library www.sll.texas.gov -Original Message- From: Margo Duncan Sent: Wednesday, April 17, 2019 15:31 To: Arturo Longoria ; Renvoize, Martin ; Koha Subject: RE: [Koha] double fines We run fines.pl hourly (it takes between 11 and 15 minutes to run) as well as CalculateFinesOnReturn set to Do and it's been set that way for a long time. We only started seeing the double fines since we upgraded to 18.11 (from 18.05) in February. Margo -Original Message- From: Koha [mailto:koha-boun...@lists.katipo.co.nz] On Behalf Of Arturo Longoria Sent: Wednesday, April 17, 2019 8:53 AM To: Renvoize, Martin ; Koha Subject: Re: [Koha] double fines Our fines.pl job runs daily, but we don't have much circulation, so while I don't have the numbers on hand (since our Koha is managed by ByWater Solutions), I can't imagine it runs longer than a few minutes. If this happens again or if I can detect some kind of pattern, I can provide an update to this thread. Arturo Longoria Reference Librarian/Web Manager Texas State Law Library https://urldefense.proofpoint.com/v2/url?u=http-3A__www.sll.texas.gov=DwIGaQ=e7TYJBzRfB0YbjEn2u3vBA=roY6qGYXhOv2NYP41kw392iquieY_agvyS3IdaEsCh0=7o-Qc-3YVcQHDSj78lAn8vvGqiaU17d5f_1wJWEC-Ls=louv4K8SfwGLaj3pogvOx3hSuzKErS0bWXLTSI5z9P4= -Original Message- From: Koha On Behalf Of Renvoize, Martin Sent: Tuesday, April 16, 2019 02:42 To: Koha Subject: Re: [Koha] double fines For those experiencing this issue, how often are you running fines.pl and what sort of overdues numbers are we talking about, does the job take minutes or hours to run to completion? It feels like we may have a race condition somewhere here. We do have a number of customers here with the fines job running nightly and the finesMode set to `Calculate and charge` along with CalculateFinesOnReturn set to `Do` and none have reported this issue to date that I'm aware of. *Martin Renvoize* <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ptfs-2Deurope.com=DwIGaQ=e7TYJBzRfB0YbjEn2u3vBA=roY6qGYXhOv2NYP41kw392iquieY_agvyS3IdaEsCh0=7o-Qc-3YVcQHDSj78lAn8vvGqiaU17d5f_1wJWEC-Ls=B-QOK2TcJ15pGvQTkg3rjYVoyGdY2Op9wr5MExuvbT4=> Development Team Manager *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvo...@ptfs-europe.com *Fax:* +44 (0) 800 756 6384 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ptfs-2Deurope.com=DwIGaQ=e7TYJBzRfB0YbjEn2u3vBA=roY6qGYXhOv2NYP41kw392iquieY_agvyS3IdaEsCh0=7o-Qc-3YVcQHDSj78lAn8vvGqiaU17d5f_1wJWEC-Ls=9zCwfMNwX8SN3zK6Qk6uEJ1RczjjB5SIX0tWa7z4V_4= Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at i...@ptfs-europe.com On Mon, 15 Apr 2019 at 22:44, Caroline Cyr-La-Rose < caroline.cyr-la-r...@inlibro.com> wrote: > I've noticed this in the past too. I always tell administrators to > choose EITHER > > * finesMode set to "Calculate and charge", with fines.pl set to run > nightly, OR > * CalculateFinesOnReturn set to "Do" > > Both turned on always gave me trouble. I thought it was meant to be a > choice between calculating fines nightly with the cron or c
Re: [Koha] double fines
Our library is still on 18.05.10, so I'm not sure it's specific to 18.11, unfortunately. A new related bug has been filed here, https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22727, but that doesn't seem to capture what's happening at our library because our WhenLostForgiveFine preference is set to "Don't Forgive," not "Forgive" as the bug description indicates. Arturo Longoria Reference Librarian/Web Manager Texas State Law Library www.sll.texas.gov -Original Message- From: Margo Duncan Sent: Wednesday, April 17, 2019 15:31 To: Arturo Longoria ; Renvoize, Martin ; Koha Subject: RE: [Koha] double fines We run fines.pl hourly (it takes between 11 and 15 minutes to run) as well as CalculateFinesOnReturn set to Do and it's been set that way for a long time. We only started seeing the double fines since we upgraded to 18.11 (from 18.05) in February. Margo -Original Message- From: Koha [mailto:koha-boun...@lists.katipo.co.nz] On Behalf Of Arturo Longoria Sent: Wednesday, April 17, 2019 8:53 AM To: Renvoize, Martin ; Koha Subject: Re: [Koha] double fines Our fines.pl job runs daily, but we don't have much circulation, so while I don't have the numbers on hand (since our Koha is managed by ByWater Solutions), I can't imagine it runs longer than a few minutes. If this happens again or if I can detect some kind of pattern, I can provide an update to this thread. Arturo Longoria Reference Librarian/Web Manager Texas State Law Library https://urldefense.proofpoint.com/v2/url?u=http-3A__www.sll.texas.gov=DwIGaQ=e7TYJBzRfB0YbjEn2u3vBA=roY6qGYXhOv2NYP41kw392iquieY_agvyS3IdaEsCh0=7o-Qc-3YVcQHDSj78lAn8vvGqiaU17d5f_1wJWEC-Ls=louv4K8SfwGLaj3pogvOx3hSuzKErS0bWXLTSI5z9P4= -Original Message- From: Koha On Behalf Of Renvoize, Martin Sent: Tuesday, April 16, 2019 02:42 To: Koha Subject: Re: [Koha] double fines For those experiencing this issue, how often are you running fines.pl and what sort of overdues numbers are we talking about, does the job take minutes or hours to run to completion? It feels like we may have a race condition somewhere here. We do have a number of customers here with the fines job running nightly and the finesMode set to `Calculate and charge` along with CalculateFinesOnReturn set to `Do` and none have reported this issue to date that I'm aware of. *Martin Renvoize* <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ptfs-2Deurope.com=DwIGaQ=e7TYJBzRfB0YbjEn2u3vBA=roY6qGYXhOv2NYP41kw392iquieY_agvyS3IdaEsCh0=7o-Qc-3YVcQHDSj78lAn8vvGqiaU17d5f_1wJWEC-Ls=B-QOK2TcJ15pGvQTkg3rjYVoyGdY2Op9wr5MExuvbT4=> Development Team Manager *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvo...@ptfs-europe.com *Fax:* +44 (0) 800 756 6384 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ptfs-2Deurope.com=DwIGaQ=e7TYJBzRfB0YbjEn2u3vBA=roY6qGYXhOv2NYP41kw392iquieY_agvyS3IdaEsCh0=7o-Qc-3YVcQHDSj78lAn8vvGqiaU17d5f_1wJWEC-Ls=9zCwfMNwX8SN3zK6Qk6uEJ1RczjjB5SIX0tWa7z4V_4= Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at i...@ptfs-europe.com On Mon, 15 Apr 2019 at 22:44, Caroline Cyr-La-Rose < caroline.cyr-la-r...@inlibro.com> wrote: > I've noticed this in the past too. I always tell administrators to > choose EITHER > > * finesMode set to "Calculate and charge", with fines.pl set to run > nightly, OR > * CalculateFinesOnReturn set to "Do" > > Both turned on always gave me trouble. I thought it was meant to be a > choice between calculating fines nightly with the cron or calculate on > return. > > Caroline > > > On 19-04-14 22 h 02, vikram zadgaonkar wrote: > > Hi, > > I am also facing same problem. I have enabled calculate fine on return. > > > > > > On Mon 15 Apr, 2019, 12:10 AM Katrin Fischer, > > > > wrote: > > > >> Hi Margo, > >> > >> I am not aware of any known bugs that fit your description. :( > >> > >> Maybe it could help to see the 2 lines in accountlines (F and FU) > >> and compare these. > >> > >> Do you have |CalculateFinesOnReturn enabled?| > >> > >> |Katrin > >> | > >> > >> > >> On 10.04.19 20:01, Margo Duncan wrote: > >>> Good afternoon, > >>> > >>> Recently we have some patrons that are being double charged fines. > >>> It > >> looks like when the item is turned in, the accruing fine (FU) > >> rema
Re: [Koha] double fines
Our fines.pl job runs daily, but we don't have much circulation, so while I don't have the numbers on hand (since our Koha is managed by ByWater Solutions), I can't imagine it runs longer than a few minutes. If this happens again or if I can detect some kind of pattern, I can provide an update to this thread. Arturo Longoria Reference Librarian/Web Manager Texas State Law Library www.sll.texas.gov -Original Message- From: Koha On Behalf Of Renvoize, Martin Sent: Tuesday, April 16, 2019 02:42 To: Koha Subject: Re: [Koha] double fines For those experiencing this issue, how often are you running fines.pl and what sort of overdues numbers are we talking about, does the job take minutes or hours to run to completion? It feels like we may have a race condition somewhere here. We do have a number of customers here with the fines job running nightly and the finesMode set to `Calculate and charge` along with CalculateFinesOnReturn set to `Do` and none have reported this issue to date that I'm aware of. *Martin Renvoize* <https://www.ptfs-europe.com> Development Team Manager *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvo...@ptfs-europe.com *Fax:* +44 (0) 800 756 6384 www.ptfs-europe.com Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at i...@ptfs-europe.com On Mon, 15 Apr 2019 at 22:44, Caroline Cyr-La-Rose < caroline.cyr-la-r...@inlibro.com> wrote: > I've noticed this in the past too. I always tell administrators to > choose EITHER > > * finesMode set to "Calculate and charge", with fines.pl set to run > nightly, OR > * CalculateFinesOnReturn set to "Do" > > Both turned on always gave me trouble. I thought it was meant to be a > choice between calculating fines nightly with the cron or calculate on > return. > > Caroline > > > On 19-04-14 22 h 02, vikram zadgaonkar wrote: > > Hi, > > I am also facing same problem. I have enabled calculate fine on return. > > > > > > On Mon 15 Apr, 2019, 12:10 AM Katrin Fischer, > > > > wrote: > > > >> Hi Margo, > >> > >> I am not aware of any known bugs that fit your description. :( > >> > >> Maybe it could help to see the 2 lines in accountlines (F and FU) > >> and compare these. > >> > >> Do you have |CalculateFinesOnReturn enabled?| > >> > >> |Katrin > >> | > >> > >> > >> On 10.04.19 20:01, Margo Duncan wrote: > >>> Good afternoon, > >>> > >>> Recently we have some patrons that are being double charged fines. > >>> It > >> looks like when the item is turned in, the accruing fine (FU) > >> remains > and a > >> fine (F) for the same amount is added as a second line. It doesn't > appear > >> to be happening to all patrons and I cannot determine a pattern. > >>> We are on version 18.11.02. > >>> > >>> Has anyone had this problem? Or any suggestions where to start > looking? > >>> Thank you! > >>> Margo > >>> > >>> Margo Duncan, MLS > >>> Head of Library Systems > >>> Robert R. Muntz Library > >>> The University of Texas at Tyler > >>> 903.566.7174 | mdun...@uttyler.edu<mailto:mdun...@uttyler.edu> > >>> > >>> ___ > >>> Koha mailing list http://koha-community.org > >>> Koha@lists.katipo.co.nz > >>> https://lists.katipo.co.nz/mailman/listinfo/koha > >> ___ > >> Koha mailing list http://koha-community.org > >> Koha@lists.katipo.co.nz > >> https://lists.katipo.co.nz/mailman/listinfo/koha > >> > > ___ > > Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz > > https://lists.katipo.co.nz/mailman/listinfo/koha > > -- > > Caroline Cyr La Rose, M.L.I.S. > > Librarian | Product Manager > > > > Phone: 1-833-465-4276, ext. 221 > > caroline.cyr-la-r...@inlibro.com > > <mailto:caroline.cyr-la-r...@inlibro.com> > > > > INLiBRO | Document Technologies Specialists | www.inLibro.com > > <http://www.inLibro.com> > ___ > Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha > ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] double fines
Our library (on version 18.05.10) has also experienced double fines. We also cannot figure out what the pattern is! The last time it happened, a patron had 2 items go into "Long Overdue (Lost)" status (which is done automatically by the long overdue cron job). They had already accrued their max fines. Upon return a few weeks later, the fines were doubled up. We also have CalculateFinesOnReturn enabled and suspect that may be the cause? I hesitate to turn it off, though, as I don't understand what the repercussions might be. And we have also had other instances that seem similar (items go Long Overdue/Lost and have accrued max fines) but upon return, they do not double up on fines. I'm not sure what other info may be helpful for debugging, but I'd be happy to provide anything I can. Arturo Longoria Reference Librarian/Web Manager Texas State Law Library www.sll.texas.gov -Original Message- From: Koha On Behalf Of vikram zadgaonkar Sent: Sunday, April 14, 2019 21:02 To: Fischer, Katrin Cc: koha list Subject: Re: [Koha] double fines Hi, I am also facing same problem. I have enabled calculate fine on return. On Mon 15 Apr, 2019, 12:10 AM Katrin Fischer, wrote: > Hi Margo, > > I am not aware of any known bugs that fit your description. :( > > Maybe it could help to see the 2 lines in accountlines (F and FU) and > compare these. > > Do you have |CalculateFinesOnReturn enabled?| > > |Katrin > | > > > On 10.04.19 20:01, Margo Duncan wrote: > > Good afternoon, > > > > Recently we have some patrons that are being double charged fines. > > It > looks like when the item is turned in, the accruing fine (FU) remains > and a fine (F) for the same amount is added as a second line. It > doesn't appear to be happening to all patrons and I cannot determine a > pattern. > > > > We are on version 18.11.02. > > > > Has anyone had this problem? Or any suggestions where to start looking? > > Thank you! > > Margo > > > > Margo Duncan, MLS > > Head of Library Systems > > Robert R. Muntz Library > > The University of Texas at Tyler > > 903.566.7174 | mdun...@uttyler.edu<mailto:mdun...@uttyler.edu> > > > > ___ > > Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz > > https://lists.katipo.co.nz/mailman/listinfo/koha > ___ > Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha > ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] No indication to patron that they have exceeded the allowed failed login attempts
Hello, I'm not sure if I've stumbled upon a bug, or if I'm not using the FailedLoginAttempts system preference correctly -- could someone offer any feedback? I'd be happy to file a bug report if it is indeed a bug! Our library is on 18.05.10. Our FailedLoginAttempts preference is set to 5. When I purposely enter the wrong password to an account, I can see that the login_attempts column for the user is incremented. But when it goes past 5, I never see the message alerting me that I've exceeded my login attempts and need to reset my password. Instead, I keep seeing the same standard message warning me about it: "You entered an incorrect username or password. Please try again! [...]" The bug indicates that I should be prompted to reset my password, but that never happens (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18314). And if I enter the correct password after exceeding 5 login attempts, I'm still blocked but without any useful feedback, so a patron would never know what's happening even if they eventually remembered their password. Upon resetting the password via the staff client, I can finally log in with the correct pw. Am I missing something? Or is this a bug? Thank you! Arturo Longoria Reference Librarian/Web Manager Texas State Law Library www.sll.texas.gov ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Display of book cover image
The jQuery snippet I'd written will need some minor editing to target which
cover art you want to hide. And keep in mind that the image has to load before
you can detect it with JavaScript, so you can't prevent an image from
displaying, but you can hide it.
This code was not in the jQuery Library on the Koha wiki, so I've added it here:
https://wiki.koha-community.org/wiki/JQuery_Library#Show_local_cover_art_instead_of_Google_Books_cover_art_if_both_are_present
Arturo Longoria
Reference Librarian/Web Manager
Texas State Law Library
www.sll.texas.gov
-Original Message-
From: Koha On Behalf Of Michael Kuhn
Sent: Wednesday, March 13, 2019 03:20
To: koha@lists.katipo.co.nz
Subject: Re: [Koha] Display of book cover image
Hi Peter
> For the book cover images, if we choose both Google book and Amazon, > for
> example, can we set up the system so that it’ll display the first > one
> available with the order of preference of our choice?
>
> Currently, it’ll display multiple images if it’s available in both of >
> them.
One way is to use Koha system preference "Coce" (see
https://bywatersolutions.com/news/koha-tutorial-cover-images-koha-opac-coce-server
for an example) - both Amazon and Google Books covers are available there.
In an earlier post to this list Arturo Longoria provided the following code -
personally I haven't tested it but you may try to include it in system
preference "OPACUserJS":
// If both local cover art and cover art from Google Books is loaded, only show
the local cover art by hiding the Google images.
$(document).ready(function() {
// Hide cover art when viewing a bib record.
if (document.location.pathname === '/cgi-bin/koha/opac-detail.pl') {
$(window).on('load', function () {
var localImage = $('#local-thumbnail-preview').find('img')[0];
if (localImage && localImage.naturalWidth > 1) {
$('#gbs-thumbnail-preview').hide();
}
}
}
// Hide cover art from the search results.
if (document.location.pathname === '/cgi-bin/koha/opac-search.pl') {
$(window).on('load', function () {
$('span[id*=local-thumbnail]').find('img').each(function () {
if ($(this)[0].naturalWidth > 1) {
$(this).parent().siblings('span').hide();
}
});
});
}
});
Hope this helps.
Best wishes: Michael
--
Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis Admin
Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz T 0041 (0)61 261 55 61
· E m...@adminkuhn.ch · W www.adminkuhn.ch
___
Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Patron_Self_Registration__Error
Mohan, My guess would be that you need to double-check your PatronSelfRegistrationBorrowerMandatoryField and PatronSelfRegistrationBorrowerUnwantedField system preferences. If you make a field mandatory but then that same field is also listed as an unwanted field in the other preference, that could cause this error. Koha would expect that field to be filled out per the mandatory field setting, but then it does not get displayed on screen for patrons to fill out per the unwanted field setting. I hope that helps! Arturo Longoria Reference Librarian/Web Manager Texas State Law Library www.sll.texas.gov -Original Message- From: Koha On Behalf Of Mohan Kumar K.V. Sent: Thursday, January 24, 2019 21:12 To: Koha Subject: [Koha] Patron_Self_Registration__Error Hi Everybody, Can you please help me to fix below mentioned Koha Patron Self Registration Issue I am using Koha version 17.05, when i tried to submit patron self registration form in OPAC, I am getting below mentioned error. I had made required settings to enable the feature, but still I am getting same error. Error - "you have not filled out all required fields. please fill in missing fields and resubmit." Thank you, Mohan ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Possible to customize date format in notices/slips?
One final update in case someone else stumbles upon this thread: my problem was
using "dateonly" in Koha 18.05. The underlying bug of a date
(borrowers.dateexpiry) appearing as a datetime was fixed for 18.05, so there
was no need to use the "dateonly" placeholder any longer, as I'd attempted.
Simply using <> in 18.05 works as expected without the
"12:00 A.M." time.
Arturo Longoria
Reference Librarian/Web Manager
Texas State Law Library
www.sll.texas.gov
-Original Message-----
From: Koha On Behalf Of Arturo Longoria
Sent: Monday, November 19, 2018 08:21
To: Jonathan Druart
Cc: koha@lists.katipo.co.nz
Subject: Re: [Koha] Possible to customize date format in notices/slips?
Hi Jonathan,
Our library was upgraded to Koha 18.05.05 this weekend, so I went back and
added the “dateonly” placeholder for the borrowers.dateexpiry field in a
notice, but I still see the same issue. Koha does not interpret it correctly
and instead just outputs “<>” in the e-mail,
which gets interpreted as an invalid HTML element. So unless I’m using it
incorrectly, I’m not sure it was fixed by bug 17981? I’ll update the bug to
document what I saw:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21829
Arturo
From: Jonathan Druart
Sent: Tuesday, November 13, 2018 09:26
To: Arturo Longoria
Cc: koha@lists.katipo.co.nz
Subject: Re: [Koha] Possible to customize date format in notices/slips?
I am not sure it's a regression actually.
in master it has been fixed by
commit a236b684fdae8e0da83ca7263b948da971dfc849
Bug 17981: Add a preview mode for notice templates
modified: C4/Letters.pm
@ Letters.pm:887 @ sub _parseletter {
my $values = $values_in ? { %$values_in } : {};
if ( $table eq 'borrowers' && $values->{'dateexpiry'} ){
-$values->{'dateexpiry'} = format_sqldatetime( $values->{'dateexpiry'}
);
+$values->{'dateexpiry'} = output_pref({ str =>
+ $values->{dateexpiry}, dateonly => 1 });
}
if ( $table eq 'reserves' && $values->{'waitingdate'} ) {
On Tue, 13 Nov 2018 at 12:21 Jonathan Druart
mailto:jonathan.dru...@bugs.koha-community.org>>
wrote:
Hi Arturo,
I do recreate on 17.11.10, not master. Can you open a bug report?
You should not need to specify the dateonly filter for dateexpiry, it's
automatically truncated to only display the date part (as there is no time
part!)
Regards,
Jonathan
On Tue, 13 Nov 2018 at 11:14 Arturo Longoria
mailto:arturo.longo...@sll.texas.gov>> wrote:
Thank you for your help, Katrin! As a follow up, I attempted to use the
dateonly placeholder for our membership expiry notice, but the generated
e-mails did not display as expected. In the notice, I used the following text
exactly, with a space before and after the pipe character: "Your account will
expire on <>." But the notices that were
generated say: "Your account will expire on <>" (with an empty left and right
angle brackets.
Our library is on Koha 17.11.10, and looking at the database schema, I see that
the borrowers.dateexpiry column is "date", not "datetime", so that could be the
reason why the dateonly placeholder doesn't work? But if that's the case, why
is the "12:00 AM" added if the db column is a date, not a datetime?
Arturo Longoria
Reference Librarian/Web Manager
Texas State Law Library
www.sll.texas.gov<http://www.sll.texas.gov>
-Original Message-
From: Koha
mailto:koha-boun...@lists.katipo.co.nz>> On
Behalf Of Katrin Fischer
Sent: Friday, November 9, 2018 00:59
To: koha@lists.katipo.co.nz<mailto:koha@lists.katipo.co.nz>
Subject: Re: [Koha] Possible to customize date format in notices/slips?
Hi Arturo,
try adding | dateonly to your placeholder variable like this:
<< biblio.timestamp | dateonly >>
Hope this helps,
Katrin
On 07.11.18 15:46, Arturo Longoria wrote:
> Our library recently enabled the MEMBERSHIP_EXPIRY notice to alert patrons of
> expiring accounts. Currently, these notices display the expiration date along
> with a time (“Your account will expire on 12/06/2018 12:00 AM”), but is there
> a way to just display the date without the time? I read through the
> information on the wiki at
> https://wiki.koha-community.org/wiki/Customising_Notices_and_Slips as well as
> the manual, but I did not find any indication that the date format can be
> customized. I thought I’d check in with the list, though, to make sure I’m
> not missing anything.
>
> Thanks for any input you may have!
>
>
> Arturo Longoria
> Reference Librarian/Web Manager
> Texas State Law Library
> www.sll.texas.gov<http://www.sll.texas.gov><http://www.sll.texas.gov/>
>
> ___
> Koha mailing list http://koha-community.org
> Koha@lists.katipo.co.nz<mail
Re: [Koha] Possible to customize date format in notices/slips?
Hi Jonathan,
Our library was upgraded to Koha 18.05.05 this weekend, so I went back and
added the “dateonly” placeholder for the borrowers.dateexpiry field in a
notice, but I still see the same issue. Koha does not interpret it correctly
and instead just outputs “<>” in the e-mail,
which gets interpreted as an invalid HTML element. So unless I’m using it
incorrectly, I’m not sure it was fixed by bug 17981? I’ll update the bug to
document what I saw:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21829
Arturo
From: Jonathan Druart
Sent: Tuesday, November 13, 2018 09:26
To: Arturo Longoria
Cc: koha@lists.katipo.co.nz
Subject: Re: [Koha] Possible to customize date format in notices/slips?
I am not sure it's a regression actually.
in master it has been fixed by
commit a236b684fdae8e0da83ca7263b948da971dfc849
Bug 17981: Add a preview mode for notice templates
modified: C4/Letters.pm
@ Letters.pm:887 @ sub _parseletter {
my $values = $values_in ? { %$values_in } : {};
if ( $table eq 'borrowers' && $values->{'dateexpiry'} ){
-$values->{'dateexpiry'} = format_sqldatetime( $values->{'dateexpiry'}
);
+$values->{'dateexpiry'} = output_pref({ str => $values->{dateexpiry},
dateonly => 1 });
}
if ( $table eq 'reserves' && $values->{'waitingdate'} ) {
On Tue, 13 Nov 2018 at 12:21 Jonathan Druart
mailto:jonathan.dru...@bugs.koha-community.org>>
wrote:
Hi Arturo,
I do recreate on 17.11.10, not master. Can you open a bug report?
You should not need to specify the dateonly filter for dateexpiry, it's
automatically truncated to only display the date part (as there is no time
part!)
Regards,
Jonathan
On Tue, 13 Nov 2018 at 11:14 Arturo Longoria
mailto:arturo.longo...@sll.texas.gov>> wrote:
Thank you for your help, Katrin! As a follow up, I attempted to use the
dateonly placeholder for our membership expiry notice, but the generated
e-mails did not display as expected. In the notice, I used the following text
exactly, with a space before and after the pipe character: "Your account will
expire on <>." But the notices that were
generated say: "Your account will expire on <>" (with an empty left and right
angle brackets.
Our library is on Koha 17.11.10, and looking at the database schema, I see that
the borrowers.dateexpiry column is "date", not "datetime", so that could be the
reason why the dateonly placeholder doesn't work? But if that's the case, why
is the "12:00 AM" added if the db column is a date, not a datetime?
Arturo Longoria
Reference Librarian/Web Manager
Texas State Law Library
www.sll.texas.gov<http://www.sll.texas.gov>
-Original Message-
From: Koha
mailto:koha-boun...@lists.katipo.co.nz>> On
Behalf Of Katrin Fischer
Sent: Friday, November 9, 2018 00:59
To: koha@lists.katipo.co.nz<mailto:koha@lists.katipo.co.nz>
Subject: Re: [Koha] Possible to customize date format in notices/slips?
Hi Arturo,
try adding | dateonly to your placeholder variable like this:
<< biblio.timestamp | dateonly >>
Hope this helps,
Katrin
On 07.11.18 15:46, Arturo Longoria wrote:
> Our library recently enabled the MEMBERSHIP_EXPIRY notice to alert patrons of
> expiring accounts. Currently, these notices display the expiration date along
> with a time (“Your account will expire on 12/06/2018 12:00 AM”), but is there
> a way to just display the date without the time? I read through the
> information on the wiki at
> https://wiki.koha-community.org/wiki/Customising_Notices_and_Slips as well as
> the manual, but I did not find any indication that the date format can be
> customized. I thought I’d check in with the list, though, to make sure I’m
> not missing anything.
>
> Thanks for any input you may have!
>
>
> Arturo Longoria
> Reference Librarian/Web Manager
> Texas State Law Library
> www.sll.texas.gov<http://www.sll.texas.gov><http://www.sll.texas.gov/>
>
> ___
> Koha mailing list http://koha-community.org
> Koha@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz>
> https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz>
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz>
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Possible to customize date format in notices/slips?
Hi Jonathan,
Thanks for your reply! I’ve browsed the Letters.pm and DateUtils.pm
(format_sqldatetime) code a bit, but I’m not clear on what the underlying issue
might be! I’ve created a bug report describing the behavior I see in 17.11.10:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21829
Arturo Longoria
Reference Librarian/Web Manager
Texas State Law Library
www.sll.texas.gov
From: Jonathan Druart
Sent: Tuesday, November 13, 2018 09:26
To: Arturo Longoria
Cc: koha@lists.katipo.co.nz
Subject: Re: [Koha] Possible to customize date format in notices/slips?
I am not sure it's a regression actually.
in master it has been fixed by
commit a236b684fdae8e0da83ca7263b948da971dfc849
Bug 17981: Add a preview mode for notice templates
modified: C4/Letters.pm
@ Letters.pm:887 @ sub _parseletter {
my $values = $values_in ? { %$values_in } : {};
if ( $table eq 'borrowers' && $values->{'dateexpiry'} ){
-$values->{'dateexpiry'} = format_sqldatetime( $values->{'dateexpiry'}
);
+$values->{'dateexpiry'} = output_pref({ str => $values->{dateexpiry},
dateonly => 1 });
}
if ( $table eq 'reserves' && $values->{'waitingdate'} ) {
On Tue, 13 Nov 2018 at 12:21 Jonathan Druart
mailto:jonathan.dru...@bugs.koha-community.org>>
wrote:
Hi Arturo,
I do recreate on 17.11.10, not master. Can you open a bug report?
You should not need to specify the dateonly filter for dateexpiry, it's
automatically truncated to only display the date part (as there is no time
part!)
Regards,
Jonathan
On Tue, 13 Nov 2018 at 11:14 Arturo Longoria
mailto:arturo.longo...@sll.texas.gov>> wrote:
Thank you for your help, Katrin! As a follow up, I attempted to use the
dateonly placeholder for our membership expiry notice, but the generated
e-mails did not display as expected. In the notice, I used the following text
exactly, with a space before and after the pipe character: "Your account will
expire on <>." But the notices that were
generated say: "Your account will expire on <>" (with an empty left and right
angle brackets.
Our library is on Koha 17.11.10, and looking at the database schema, I see that
the borrowers.dateexpiry column is "date", not "datetime", so that could be the
reason why the dateonly placeholder doesn't work? But if that's the case, why
is the "12:00 AM" added if the db column is a date, not a datetime?
Arturo Longoria
Reference Librarian/Web Manager
Texas State Law Library
www.sll.texas.gov<http://www.sll.texas.gov>
-Original Message-
From: Koha
mailto:koha-boun...@lists.katipo.co.nz>> On
Behalf Of Katrin Fischer
Sent: Friday, November 9, 2018 00:59
To: koha@lists.katipo.co.nz<mailto:koha@lists.katipo.co.nz>
Subject: Re: [Koha] Possible to customize date format in notices/slips?
Hi Arturo,
try adding | dateonly to your placeholder variable like this:
<< biblio.timestamp | dateonly >>
Hope this helps,
Katrin
On 07.11.18 15:46, Arturo Longoria wrote:
> Our library recently enabled the MEMBERSHIP_EXPIRY notice to alert patrons of
> expiring accounts. Currently, these notices display the expiration date along
> with a time (“Your account will expire on 12/06/2018 12:00 AM”), but is there
> a way to just display the date without the time? I read through the
> information on the wiki at
> https://wiki.koha-community.org/wiki/Customising_Notices_and_Slips as well as
> the manual, but I did not find any indication that the date format can be
> customized. I thought I’d check in with the list, though, to make sure I’m
> not missing anything.
>
> Thanks for any input you may have!
>
>
> Arturo Longoria
> Reference Librarian/Web Manager
> Texas State Law Library
> www.sll.texas.gov<http://www.sll.texas.gov><http://www.sll.texas.gov/>
>
> ___
> Koha mailing list http://koha-community.org
> Koha@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz>
> https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz>
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz>
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Possible to customize date format in notices/slips?
Thank you for your help, Katrin! As a follow up, I attempted to use the dateonly placeholder for our membership expiry notice, but the generated e-mails did not display as expected. In the notice, I used the following text exactly, with a space before and after the pipe character: "Your account will expire on <>." But the notices that were generated say: "Your account will expire on <>" (with an empty left and right angle brackets. Our library is on Koha 17.11.10, and looking at the database schema, I see that the borrowers.dateexpiry column is "date", not "datetime", so that could be the reason why the dateonly placeholder doesn't work? But if that's the case, why is the "12:00 AM" added if the db column is a date, not a datetime? Arturo Longoria Reference Librarian/Web Manager Texas State Law Library www.sll.texas.gov -Original Message- From: Koha On Behalf Of Katrin Fischer Sent: Friday, November 9, 2018 00:59 To: koha@lists.katipo.co.nz Subject: Re: [Koha] Possible to customize date format in notices/slips? Hi Arturo, try adding | dateonly to your placeholder variable like this: << biblio.timestamp | dateonly >> Hope this helps, Katrin On 07.11.18 15:46, Arturo Longoria wrote: > Our library recently enabled the MEMBERSHIP_EXPIRY notice to alert patrons of > expiring accounts. Currently, these notices display the expiration date along > with a time (“Your account will expire on 12/06/2018 12:00 AM”), but is there > a way to just display the date without the time? I read through the > information on the wiki at > https://wiki.koha-community.org/wiki/Customising_Notices_and_Slips as well as > the manual, but I did not find any indication that the date format can be > customized. I thought I’d check in with the list, though, to make sure I’m > not missing anything. > > Thanks for any input you may have! > > > Arturo Longoria > Reference Librarian/Web Manager > Texas State Law Library > www.sll.texas.gov<http://www.sll.texas.gov/> > > ___ > Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Possible to customize date format in notices/slips?
Our library recently enabled the MEMBERSHIP_EXPIRY notice to alert patrons of expiring accounts. Currently, these notices display the expiration date along with a time (“Your account will expire on 12/06/2018 12:00 AM”), but is there a way to just display the date without the time? I read through the information on the wiki at https://wiki.koha-community.org/wiki/Customising_Notices_and_Slips as well as the manual, but I did not find any indication that the date format can be customized. I thought I’d check in with the list, though, to make sure I’m not missing anything. Thanks for any input you may have! Arturo Longoria Reference Librarian/Web Manager Texas State Law Library www.sll.texas.gov<http://www.sll.texas.gov/> ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Apostrophes in search terms
Hello all, Our library is having issues with items in our collection that include apostrophes in the title – for example, O'Connor's Texas Causes of Action. Basically, if a user does not include the apostrophes, Koha does not return the record. I found this bug filed in 2010 that still has no resolution describing similar issues with apostrophes and other punctuation marks when using Zebra, which we are: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5534 What are other libraries doing to get around this usability issue? We can't expect our users to always include apostrophes, and so the only solution we've come up with is adding additional titles (MARC 246$a) that don't use apostrophes, but we have thousands of records, so adding these manually is not feasible. I'm curious to hear what other libraries are doing to get around this issue. Any input would be appreciated! Arturo Longoria Reference Librarian/Web Manager Texas State Law Library www.sll.texas.gov ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Book Cover
Hi Victoria, There is no option within Koha to prioritize locally uploaded cover art, but our library has the same issue, so I wrote some JavaScript and placed it in the OPACUserJS system preference to hide any other cover art from Google if there is local cover art. I believe this should work to also hide Amazon images, but I haven't tested that. This does not block the other cover art from loading, but it does quickly hide it for a better display. The code I use is here: https://pastebin.com/F2nQdHaz Arturo Longoria Reference Librarian/Web Manager Texas State Law Library www.sll.texas.gov -Original Message- From: Koha [mailto:koha-boun...@lists.katipo.co.nz] On Behalf Of Ma. Victoria H. Silva-Manuel Sent: Wednesday, March 07, 2018 20:12 To: koha <koha@lists.katipo.co.nz> Subject: [Koha] Book Cover Hi. Is there a way to show one cover image only. I mean, if I had uploaded a local image, the image from Amazon or Google won't show anymore for a particular book/record. Thank you. -- Ma. Victoria H. Silva-Manuel Registered Librarian, 3892 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] How does the AutoEmailOpacUser preference work?
Katrin, Looking at my notes from when I tested this feature out a few weeks ago, I noted that I had to keep the username empty and fill out both the password fields and the primary e-mail address field in order for the e-mail to go out. I did not have success if I also filled out the username. -Original Message- From: Koha [mailto:koha-boun...@lists.katipo.co.nz] On Behalf Of Katrin Fischer Sent: Wednesday, January 31, 2018 01:33 To: koha@lists.katipo.co.nz Subject: Re: [Koha] How does the AutoEmailOpacUser preference work? Hi Arturo, looking at the code I think you need to set the username, password and one of the email addresses before saving the patron for the first time in order for the email to be generated. Hope this helps, Katrin On 08.01.2018 17:48, Barton Chittenden wrote: > Arturo, > > Check the basics first -- are the email addresses valid? Are the > messages in the patron's spam folder? > > Next I would check is email logs -- typically /var/log/mail.log > > Grep for the email address. If you see that messages have been sent, > there's not much you can do; the issue is entirely upstream. > > On the other hand, you may see that the emails are being rejected by > the upstream mail server, in which case you'll need to contact the server > admin. > > > On Mon, Jan 8, 2018 at 11:41 AM, Arturo Longoria < > arturo.longo...@sll.texas.gov> wrote: > >> Hello, >> >> Our library enabled the AutoEmailOpacUser preference so that patrons >> receive a notification of their account details when we create an >> account for them via the staff client -- http://manual.koha-community. >> org/17.11/en/administration.html#AutoEmailOPACUser -- and we've set >> AutoEmailPrimaryAddress to use the first valid e-mail found in the account. >> >> But we've noticed that the e-mail is not always sent when the account >> includes a valid e-mail. The documentation does not mention any >> specifics, so I was wondering if anyone can explain how this feature works? >> >> It seems to be sent only if the username field is blank AND there is >> a password included. I've found that if staff do not include a value >> in the password fields, the e-mail is not sent. If the password >> fields are filled out and staff also include a username, the e-mail is not >> sent. >> >> Is this the intended behavior? >> >> >> Arturo Longoria >> Reference Librarian/Web Manager >> Texas State Law Library >> www.sll.texas.gov >> >> ___ >> Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz >> https://lists.katipo.co.nz/mailman/listinfo/koha >> > ___ > Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] How does the AutoEmailOpacUser preference work?
Barton, I've been testing by creating new accounts that use my own e-mail address and checking my own spam folder, so I feel I've ruled those variables out. I don't have access to the server's /var/log/mail.log, so I can't check that, unfortunately. But I do find it to be consistent that I will only receive the ACCTDETAILS e-mail if the username field is blank (so that Koha generates it automatically) and manually enter a password for the account. If I omit the pw, no e-mail. If I enter a custom username, no e-mail. Unless the log says otherwise, I don't believe Koha is generating the e-mail in those instances. From: Barton Chittenden [mailto:bar...@bywatersolutions.com] Sent: Monday, January 08, 2018 10:49 To: Arturo Longoria <arturo.longo...@sll.texas.gov> Cc: Koha <koha@lists.katipo.co.nz> Subject: Re: [Koha] How does the AutoEmailOpacUser preference work? Arturo, Check the basics first -- are the email addresses valid? Are the messages in the patron's spam folder? Next I would check is email logs -- typically /var/log/mail.log Grep for the email address. If you see that messages have been sent, there's not much you can do; the issue is entirely upstream. On the other hand, you may see that the emails are being rejected by the upstream mail server, in which case you'll need to contact the server admin. On Mon, Jan 8, 2018 at 11:41 AM, Arturo Longoria <arturo.longo...@sll.texas.gov<mailto:arturo.longo...@sll.texas.gov>> wrote: Hello, Our library enabled the AutoEmailOpacUser preference so that patrons receive a notification of their account details when we create an account for them via the staff client -- http://manual.koha-community.org/17.11/en/administration.html#AutoEmailOPACUser -- and we've set AutoEmailPrimaryAddress to use the first valid e-mail found in the account. But we've noticed that the e-mail is not always sent when the account includes a valid e-mail. The documentation does not mention any specifics, so I was wondering if anyone can explain how this feature works? It seems to be sent only if the username field is blank AND there is a password included. I've found that if staff do not include a value in the password fields, the e-mail is not sent. If the password fields are filled out and staff also include a username, the e-mail is not sent. Is this the intended behavior? Arturo Longoria Reference Librarian/Web Manager Texas State Law Library www.sll.texas.gov<http://www.sll.texas.gov> ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz> https://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] How does the AutoEmailOpacUser preference work?
Hello, Our library enabled the AutoEmailOpacUser preference so that patrons receive a notification of their account details when we create an account for them via the staff client -- http://manual.koha-community.org/17.11/en/administration.html#AutoEmailOPACUser -- and we've set AutoEmailPrimaryAddress to use the first valid e-mail found in the account. But we've noticed that the e-mail is not always sent when the account includes a valid e-mail. The documentation does not mention any specifics, so I was wondering if anyone can explain how this feature works? It seems to be sent only if the username field is blank AND there is a password included. I've found that if staff do not include a value in the password fields, the e-mail is not sent. If the password fields are filled out and staff also include a username, the e-mail is not sent. Is this the intended behavior? Arturo Longoria Reference Librarian/Web Manager Texas State Law Library www.sll.texas.gov ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Bug: passwords should be HTML-encoded when displayed during self-registration
Thank you again for your quick work, Jonathan! I've tested your patches on a sandbox and they work great! I've updated the bug with my notes because I did find one small typo (the patch is missing a closing HTML span tag). I wasn't sure if I should sign-off yet because of that, so I'll hold off on that for now. Thanks again – very much appreciate your work! Arturo From: Jonathan Druart [mailto:jonathan.dru...@bugs.koha-community.org] Sent: Wednesday, January 03, 2018 13:17 To: Arturo Longoria <arturo.longo...@sll.texas.gov> Cc: Koha <koha@lists.katipo.co.nz> Subject: Re: [Koha] Bug: passwords should be HTML-encoded when displayed during self-registration Patch attached, please test. On Wed, 3 Jan 2018 at 15:50 Arturo Longoria <arturo.longo...@sll.texas.gov<mailto:arturo.longo...@sll.texas.gov>> wrote: Hi, all. Our library uses self-registration quite a bit, and I've recently stumbled upon a bug that can occur when Koha generates a random password for a user during self-registration and attempts to display it to the user since these passwords are not HTML-encoded. I have documented the bug here: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19911. Basically, the PatronSelfRegistrationPrefillForm preference can be set so that self-registered patrons are shown their password upon creating an account. This setting is necessary at our library because we do not allow patrons to select their own passwords during self-registration due to bug 19845, https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19845. If the password that is generated randomly by Koha contains the less-than character, <, browsers think that this is the beginning of an HTML element, so the less-than character and anything after it are not displayed to the user. This means that users are not shown their full password! This screenshot illustrates what I'm describing: https://i.imgur.com/hlKpU1I.png. Arturo Longoria Reference Librarian/Web Manager Texas State Law Library www.sll.texas.gov<http://www.sll.texas.gov><http://www.sll.texas.gov/> ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz> https://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Bug: passwords should be HTML-encoded when displayed during self-registration
Hi, all. Our library uses self-registration quite a bit, and I've recently stumbled upon a bug that can occur when Koha generates a random password for a user during self-registration and attempts to display it to the user since these passwords are not HTML-encoded. I have documented the bug here: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19911. Basically, the PatronSelfRegistrationPrefillForm preference can be set so that self-registered patrons are shown their password upon creating an account. This setting is necessary at our library because we do not allow patrons to select their own passwords during self-registration due to bug 19845, https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19845. If the password that is generated randomly by Koha contains the less-than character, <, browsers think that this is the beginning of an HTML element, so the less-than character and anything after it are not displayed to the user. This means that users are not shown their full password! This screenshot illustrates what I'm describing: https://i.imgur.com/hlKpU1I.png. Arturo Longoria Reference Librarian/Web Manager Texas State Law Library www.sll.texas.gov<http://www.sll.texas.gov/> ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Allowing patrons to set their passwords during self-registration
Hi Jonathan, You are awesome! Thank you so much for working on this and submitting a patch so quickly! I just tested and your patch worked like a charm. I've updated the filed bug with a sign-off and my notes: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19845 In short, I tested various configurations of (a) requiring e-mail verification and (b) requiring or allowing users to select their own passwords during self-registrations, and it worked as expected for all of my tests. The user-supplied password was always used if entered, regardless of e-mail verification settings. And a random password was always generated if users did not select their own password, regardless of e-mail verification settings. Thanks again! Arturo From: Jonathan Druart [mailto:jonathan.dru...@bugs.koha-community.org] Sent: Wednesday, December 20, 2017 09:39 To: Arturo Longoria <arturo.longo...@sll.texas.gov> Cc: Koha <koha@lists.katipo.co.nz> Subject: Re: [Koha] Allowing patrons to set their passwords during self-registration Hi Arturo, I have attached a patch on the bug report you opened. Please test and confirm it fixes your issue. Regards, Jonathan On Tue, 19 Dec 2017 at 18:38 Arturo Longoria <arturo.longo...@sll.texas.gov<mailto:arturo.longo...@sll.texas.gov>> wrote: Hi Liz, Thank you for your tip on how to access the queued e-mail messages! With that information, I was able to view the generated e-mail from this morning and can confirm what I'd suspected -- Koha will ignore the user-supplied password during self-registration if e-mail verification is required. I have filed a bug for this behavior: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19845 Arturo -Original Message- From: Koha [mailto:koha-boun...@lists.katipo.co.nz<mailto:koha-boun...@lists.katipo.co.nz>] On Behalf Of Liz Rea Sent: Tuesday, December 19, 2017 14:52 To: Koha-Mailinglist <Koha@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz>> Subject: Re: [Koha] Allowing patrons to set their passwords during self-registration Hi Arturo, While I haven't tested your scenario precisely, it's possible that the reason that you are having problems here is that we don't want to set a password before the account has been confirmed via email. A possible shortcoming of the feature is that it doesn't take this into account (but haven't tested it so don't take that as absolute truth). Regarding the emails, you can see the registration emails and links by putting this report into your saved sql reports: select to_address, content, time_queued from message_queue where date(time_queued) = CURDATE(); Then copy/paste the link from the content into your browser. The sandboxes don't send mail for a very good reason, to keep spammers from using them for evil. Good luck, happy testing, Liz Catalyst IT ps with apologies to Arturo, I didn't send this to the list and I should have, so sending it again. On 20/12/17 07:12, Arturo Longoria wrote: > No solution yet. I have a suspicion that the problem I'm seeing is because > our library has the PatronSelfRegistrationVerifyByEmail set to "Require" > rather than "Don't require." > > I set up sandbox 6 from BibLibre to test this theory out with master, and if > I set the preference to "Don't require," it will allow me to set my own > password during self-registration without issue after I configure it to > require a password during self-registration. The account is created > successfully and with the password I indicated. > > I then wanted to test it out with "Require," but I'm experiencing an issue > with the sandbox not sending out any e-mails. I've added an e-mail address to > the KohaAdminEmailAddress per the instructions in the wiki, but no luck -- > e-mails are not being sent at all, so I'm not able to test whether it will > allow me to keep the password I entered in the form once I verify my e-mail. > > Other than entering a valid e-mail in KohaAdminEmailAddress, is there > anything else I would need to do in the sandbox to have Koha send e-mails? > I'd like to make sure this is a bug before entering it to Bugzilla. > > Arturo > > -Original Message- > From: Koha > [mailto:koha-boun...@lists.katipo.co.nz<mailto:koha-boun...@lists.katipo.co.nz>] > On Behalf Of > Christopher Davis > Sent: Tuesday, December 19, 2017 12:00 > To: Katrin Fischer <katrin.fischer...@web.de<mailto:katrin.fischer...@web.de>> > Cc: Koha <koha@lists.katipo.co.nz<mailto:koha@lists.katipo.co.nz>> > Subject: Re: [Koha] Allowing patrons to set their passwords during > self-registration > > Arturo, > > I would also be interested in the status of this feature. > > Thank you, > > Christopher Davis > Systems & E-Services Librarian > Uinta
Re: [Koha] Allowing patrons to set their passwords during self-registration
Interesting... I've tested this on 16.11, 17.05, and I am now testing it on the 'master' branch in a Koha sandbox. I just tried it again now to be sure, and even though I specify a password in the self-registration form, once I use the verification link, the auto-generated password is displayed and it will not let me log in if I try using the password I had specified in the form. It only accepts the auto-generated pw. If it's working in your situation and you don't need the login form to be pre-filled, I think it would be a matter of toggling the PatronSelfRegistrationPrefillForm preference so that it doesn't display. -Original Message- From: Hugh Rundle [mailto:hu...@brimbank.vic.gov.au] Sent: Tuesday, December 19, 2017 16:03 To: Arturo Longoria <arturo.longo...@sll.texas.gov>; Koha <koha@lists.katipo.co.nz> Subject: RE: [Koha] Allowing patrons to set their passwords during self-registration Hi Arturo et al What version are you using? We're on 16.11 and using this exact scenario. In our setup: * Online registration allows for patron to enter their own password * Account must be confirmed using the link in the confirmation email * The password the patron created is the one that works * The auto-generated password (that does not work) is displayed on the confirmation screen along with their login Obviously the last point is problematic, but that may simply be a setting I've got wrong. Hugh Rundle Library Systems & Resource Coordinator Community Learning & Participation Brimbank City Council Brimbank Community and Civic Centre - 301 Hampshire Road, Sunshine T +61 3 9249 4170 M +61 437 734 108 F +61 3 9249 4351 www.brimbank.vic.gov.au -Original Message- From: Koha [mailto:koha-boun...@lists.katipo.co.nz] On Behalf Of Arturo Longoria Sent: Wednesday, 20 December 2017 8:38 AM To: Koha Subject: Re: [Koha] Allowing patrons to set their passwords during self-registration Hi Liz, Thank you for your tip on how to access the queued e-mail messages! With that information, I was able to view the generated e-mail from this morning and can confirm what I'd suspected -- Koha will ignore the user-supplied password during self-registration if e-mail verification is required. I have filed a bug for this behavior: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19845 Arturo -Original Message- From: Koha [mailto:koha-boun...@lists.katipo.co.nz] On Behalf Of Liz Rea Sent: Tuesday, December 19, 2017 14:52 To: Koha-Mailinglist <Koha@lists.katipo.co.nz> Subject: Re: [Koha] Allowing patrons to set their passwords during self-registration Hi Arturo, While I haven't tested your scenario precisely, it's possible that the reason that you are having problems here is that we don't want to set a password before the account has been confirmed via email. A possible shortcoming of the feature is that it doesn't take this into account (but haven't tested it so don't take that as absolute truth). Regarding the emails, you can see the registration emails and links by putting this report into your saved sql reports: select to_address, content, time_queued from message_queue where date(time_queued) = CURDATE(); Then copy/paste the link from the content into your browser. The sandboxes don't send mail for a very good reason, to keep spammers from using them for evil. Good luck, happy testing, Liz Catalyst IT ps with apologies to Arturo, I didn't send this to the list and I should have, so sending it again. On 20/12/17 07:12, Arturo Longoria wrote: > No solution yet. I have a suspicion that the problem I'm seeing is because > our library has the PatronSelfRegistrationVerifyByEmail set to "Require" > rather than "Don't require." > > I set up sandbox 6 from BibLibre to test this theory out with master, and if > I set the preference to "Don't require," it will allow me to set my own > password during self-registration without issue after I configure it to > require a password during self-registration. The account is created > successfully and with the password I indicated. > > I then wanted to test it out with "Require," but I'm experiencing an issue > with the sandbox not sending out any e-mails. I've added an e-mail address to > the KohaAdminEmailAddress per the instructions in the wiki, but no luck -- > e-mails are not being sent at all, so I'm not able to test whether it will > allow me to keep the password I entered in the form once I verify my e-mail. > > Other than entering a valid e-mail in KohaAdminEmailAddress, is there > anything else I would need to do in the sandbox to have Koha send e-mails? > I'd like to make sure this is a bug before entering it to Bugzilla. > > Arturo > > -Original Message- > From: Koha [mailto:koha-boun...@lists.katipo.co.nz] On Behalf Of > Christopher Davis >
Re: [Koha] Allowing patrons to set their passwords during self-registration
Hi Liz, Thank you for your tip on how to access the queued e-mail messages! With that information, I was able to view the generated e-mail from this morning and can confirm what I'd suspected -- Koha will ignore the user-supplied password during self-registration if e-mail verification is required. I have filed a bug for this behavior: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19845 Arturo -Original Message- From: Koha [mailto:koha-boun...@lists.katipo.co.nz] On Behalf Of Liz Rea Sent: Tuesday, December 19, 2017 14:52 To: Koha-Mailinglist <Koha@lists.katipo.co.nz> Subject: Re: [Koha] Allowing patrons to set their passwords during self-registration Hi Arturo, While I haven't tested your scenario precisely, it's possible that the reason that you are having problems here is that we don't want to set a password before the account has been confirmed via email. A possible shortcoming of the feature is that it doesn't take this into account (but haven't tested it so don't take that as absolute truth). Regarding the emails, you can see the registration emails and links by putting this report into your saved sql reports: select to_address, content, time_queued from message_queue where date(time_queued) = CURDATE(); Then copy/paste the link from the content into your browser. The sandboxes don't send mail for a very good reason, to keep spammers from using them for evil. Good luck, happy testing, Liz Catalyst IT ps with apologies to Arturo, I didn't send this to the list and I should have, so sending it again. On 20/12/17 07:12, Arturo Longoria wrote: > No solution yet. I have a suspicion that the problem I'm seeing is because > our library has the PatronSelfRegistrationVerifyByEmail set to "Require" > rather than "Don't require." > > I set up sandbox 6 from BibLibre to test this theory out with master, and if > I set the preference to "Don't require," it will allow me to set my own > password during self-registration without issue after I configure it to > require a password during self-registration. The account is created > successfully and with the password I indicated. > > I then wanted to test it out with "Require," but I'm experiencing an issue > with the sandbox not sending out any e-mails. I've added an e-mail address to > the KohaAdminEmailAddress per the instructions in the wiki, but no luck -- > e-mails are not being sent at all, so I'm not able to test whether it will > allow me to keep the password I entered in the form once I verify my e-mail. > > Other than entering a valid e-mail in KohaAdminEmailAddress, is there > anything else I would need to do in the sandbox to have Koha send e-mails? > I'd like to make sure this is a bug before entering it to Bugzilla. > > Arturo > > -Original Message- > From: Koha [mailto:koha-boun...@lists.katipo.co.nz] On Behalf Of > Christopher Davis > Sent: Tuesday, December 19, 2017 12:00 > To: Katrin Fischer <katrin.fischer...@web.de> > Cc: Koha <koha@lists.katipo.co.nz> > Subject: Re: [Koha] Allowing patrons to set their passwords during > self-registration > > Arturo, > > I would also be interested in the status of this feature. > > Thank you, > > Christopher Davis > Systems & E-Services Librarian > Uintah County Library > cgda...@uintah.utah.gov > (435) 789-0091 <14357890091> ext.261 > uintahlibrary.org > basinlibraries.org > facebook.com/uintahcountylibrary > instagram.com/uintahcountylibrary > > > On Mon, Dec 18, 2017 at 3:12 PM, Katrin Fischer > <katrin.fischer...@web.de> > wrote: > >> Hi Arturo, >> >> have you been able to solve this? It should work with the >> configuration you described. If it's still an issue, please consider >> filing a bug report on http://bugs.koha-community.org >> >> Katrin >> >> >> On 29.11.2017 15:18, Arturo Longoria wrote: >> >>> What I do is I remove "password" from the >>> PatronSelfRegistrationBorrowerUnwantedField >>> preference and add "password" to the PatronSelfRegistra >>> >> ___ >> Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz >> https://lists.katipo.co.nz/mailman/listinfo/koha >> > ___ > Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha > ___ > Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha -- -- Liz Rea Catalyst.Net Limited Level 6, Catalyst House, 150 Willis St
Re: [Koha] Allowing patrons to set their passwords during self-registration
No solution yet. I have a suspicion that the problem I'm seeing is because our library has the PatronSelfRegistrationVerifyByEmail set to "Require" rather than "Don't require." I set up sandbox 6 from BibLibre to test this theory out with master, and if I set the preference to "Don't require," it will allow me to set my own password during self-registration without issue after I configure it to require a password during self-registration. The account is created successfully and with the password I indicated. I then wanted to test it out with "Require," but I'm experiencing an issue with the sandbox not sending out any e-mails. I've added an e-mail address to the KohaAdminEmailAddress per the instructions in the wiki, but no luck -- e-mails are not being sent at all, so I'm not able to test whether it will allow me to keep the password I entered in the form once I verify my e-mail. Other than entering a valid e-mail in KohaAdminEmailAddress, is there anything else I would need to do in the sandbox to have Koha send e-mails? I'd like to make sure this is a bug before entering it to Bugzilla. Arturo -Original Message- From: Koha [mailto:koha-boun...@lists.katipo.co.nz] On Behalf Of Christopher Davis Sent: Tuesday, December 19, 2017 12:00 To: Katrin Fischer <katrin.fischer...@web.de> Cc: Koha <koha@lists.katipo.co.nz> Subject: Re: [Koha] Allowing patrons to set their passwords during self-registration Arturo, I would also be interested in the status of this feature. Thank you, Christopher Davis Systems & E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 <14357890091> ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary instagram.com/uintahcountylibrary On Mon, Dec 18, 2017 at 3:12 PM, Katrin Fischer <katrin.fischer...@web.de> wrote: > Hi Arturo, > > have you been able to solve this? It should work with the > configuration you described. If it's still an issue, please consider > filing a bug report on http://bugs.koha-community.org > > Katrin > > > On 29.11.2017 15:18, Arturo Longoria wrote: > >> What I do is I remove "password" from the >> PatronSelfRegistrationBorrowerUnwantedField >> preference and add "password" to the PatronSelfRegistra >> > > ___ > Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha > ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Allowing patrons to set their passwords during self-registration
Hello, everyone! I was hoping I could get some help or input from the list about an issue our library is experiencing. We use Koha 17.05. We allow patrons to self-register an account, and their passwords are generated by Koha and shown to them after they click on the e-mail verification link as part of the registration process. With bug 15343 having been incorporated as of version 16.05 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15343), we wanted to switch over to having patrons select their own passwords during self-registration. I have followed the instructions outlined as part of the bug's test plan, but I cannot get this to work – Koha keeps ignoring the user-supplied password and generates a random password. What I do is I remove "password" from the PatronSelfRegistrationBorrowerUnwantedField preference and add "password" to the PatronSelfRegistrationBorrowerMandatoryField preference since we want to make this a required field. I'll then go to the self-registration form, fill out all of the required fields, including the password fields that are now marked as required, and wait for the self-registration verification e-mail. When I click on the link in the e-mail, I'm shown my new username and a new, random password – not the one I had entered in the form! I've tried turning off the PatronSelfRegistrationPrefillForm preference in case that was an issue, but in those cases, I can only assume a random password was generated because I still can't login with the password I supplied in the form. Any thoughts on what I might be missing or what could be the issue? I'd appreciate any input! Thank you, Arturo Longoria Reference Librarian/Web Manager Texas State Law Library ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] strange behavior with a public report
Hi all,
I've come across strange behavior with a public report in Koha since our
library was upgraded to 3.18. I'm not sure if it is a bug or if I am doing
something incorrectly, and so I thought I'd ask for some input.
I've created a custom SQL report that will output basic bibliographic data for
titles that are included in a list (virtual shelf), and I have marked this
report as public so that I can access its JSON output via
/cgi-bin/koha/svc/report?id={report id}sql_params={virtual shelf number} on
the public side. The issue I'm having is that if I run this report within the
staff client, it works perfectly. If I edit the list by adding/removing titles
to it and then re-run the report in the staff client, everything is displayed
as expected.
But if I run the report on the public side to get the JSON output, the report
will only show me bib. info for the titles that were originally saved in the
list! That is, when I first create a list and access its JSON output, it works
fine. But if I then edit the list by removing a title or adding a new title,
the JSON output is not updated – it continues to show me the old contents of
the list. If I run the report through the staff client, though, it does show me
the updated contents of the list! The two outputs are different.
Any ideas on what could be causing this? The report's settings have a cache
expiry of 0 seconds (the default). I've tried setting different cache expiry
periods to see if that is the issue, but that seems to do nothing. The SQL is a
very simple select statement:
SELECT biblionumber, author, title, seriestitle, copyrightdate, notes, abstract
FROM virtualshelfcontents vsc LEFT JOIN biblio using (biblionumber)
WHERE vsc.shelfnumber = Enter shelf number
Arturo Longoria
Texas State Law Library
www.sll.texas.govhttp://www.sll.texas.gov/
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] strange behavior with a public report
Ah, I hadn't considered that possibility, but unfortunately, I don't think
that's the cause. SvcMaxReportsRow is set to 300 rows, and the lists I am
creating don't ever contain more than 6 titles.
-Original Message-
From: Barry Cannon [mailto:b...@interleaf.ie]
Sent: Wednesday, May 13, 2015 09:31
To: Arturo Longoria; koha@lists.katipo.co.nz
Subject: RE: strange behavior with a public report
Could it be the SvcMaxReportRows Syspref is set to it's default of 10. This
could be only displaying the first 10 biblios everytime the report is run?
Regards
Barry Cannon
Interleaf Technology
http://www.interleaf.ie
Tel: +35312865855
Email: b...@interleaf.ie
Skype: bar.cannon
From: Koha [koha-boun...@lists.katipo.co.nz] on behalf of Arturo Longoria
[arturo.longo...@sll.texas.gov]
Sent: 13 May 2015 15:18
To: koha@lists.katipo.co.nz
Subject: [Koha] strange behavior with a public report
Hi all,
I've come across strange behavior with a public report in Koha since our
library was upgraded to 3.18. I'm not sure if it is a bug or if I am doing
something incorrectly, and so I thought I'd ask for some input.
I've created a custom SQL report that will output basic bibliographic data for
titles that are included in a list (virtual shelf), and I have marked this
report as public so that I can access its JSON output via
/cgi-bin/koha/svc/report?id={report id}sql_params={virtual shelf number} on
the public side. The issue I'm having is that if I run this report within the
staff client, it works perfectly. If I edit the list by adding/removing titles
to it and then re-run the report in the staff client, everything is displayed
as expected.
But if I run the report on the public side to get the JSON output, the report
will only show me bib. info for the titles that were originally saved in the
list! That is, when I first create a list and access its JSON output, it works
fine. But if I then edit the list by removing a title or adding a new title,
the JSON output is not updated – it continues to show me the old contents of
the list. If I run the report through the staff client, though, it does show me
the updated contents of the list! The two outputs are different.
Any ideas on what could be causing this? The report's settings have a cache
expiry of 0 seconds (the default). I've tried setting different cache expiry
periods to see if that is the issue, but that seems to do nothing. The SQL is a
very simple select statement:
SELECT biblionumber, author, title, seriestitle, copyrightdate, notes, abstract
FROM virtualshelfcontents vsc LEFT JOIN biblio using (biblionumber)
WHERE vsc.shelfnumber = Enter shelf number
Arturo Longoria
Texas State Law Library
www.sll.texas.gov
___
Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
