August 2017 - Koha-bugs - lists.koha-community.org

[Bug 14803] Rental and fine fees are not updating on circulation screen
by bugzilla-daemon＠bugs.koha-community.org 09 Aug '17

09 Aug '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14803 Srdjan Jankovic <srdjan(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60629|0 |1 is obsolete| | --- Comment #34 from Srdjan Jankovic <srdjan(a)catalyst.net.nz> --- Created attachment 65696 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=65696&action=ed… Bug 14803: Reload checkouts table on renewal svc/checkouts: get real rental charges for patron, rather than itemtype indication -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12566] Duplicate checks for Self Registered borrowers
by bugzilla-daemon＠bugs.koha-community.org 09 Aug '17

09 Aug '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12566 --- Comment #4 from Liz Rea <liz(a)catalyst.net.nz> --- I agree with Emma, this needs to be at least as robust as the staff client duplicate borrower checking. I envision some scenarios as follows: Let's just say we have a user who has registered a year or two ago, and can't remember they did. This person registered in the library, using a paper form, and their data was input into the system by a librarian based on the fields required in the staff interface. I'm going to assume for the sake of the exercise, that the library allows users to reset their own password by email. This person now comes to the library website, and has forgotten their username/password. They don't remember that they have even used the library website before (maybe they haven't). This user cannot accomplish what they want to without an account, so they decide to register. Sensible. User registers online, using the form specified by the library. Koha will then check those required fields and look for a user in the existing database that matches to some great extent, i.e. if we ask for 10 items of information, let's say if 6 match and one is an email address in any of the address fields, we have a suspected duplicate user. At this point, we can do one of several things: 1. suggest to the user that maybe they've already registered, please go to the library (which one?) because sorry we can't resolve this online. This is ok, but pretty bad service for a modern web app. 2. If we have a matching email address in any of the email fields (configurable?), and a strongly suspected duplicate, send an email with password recovery instructions to the matching email account. The user may not have access to this account - but that isn't our problem. It is much better than sending them away! Something like "We noticed you were trying to register, but we think you might already be registered with the library. Would you like us to email you information on how to recover your account?" If accepted, the email would help them reset their password and take them through the "forgotten password" workflow. If the user declines, send them to the library for in-person help. Alternately, we could If we have a strongly suspected duplicate, but no email address in any collected email field, we would not offer to send anything - "We can't register you online, sorry." 3. add the user but flag it with MANY FLAGS AND BLINK TAGS as PROBABLY DUPLICATE and note which borrower, and put it in the patron modification queue for a librarian to merge with the existing user. We will want to prefer the username and password that the user has just created with the new registration so they can still log in. There are other scenarios but I don't really have clearance to think about them right now. I do welcome discussion. Cheers, Liz -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 12935] Allow different from_address in the message_queue
by bugzilla-daemon＠bugs.koha-community.org 09 Aug '17

09 Aug '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12935 M. Tompsett <mtompset(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from M. Tompsett <mtompset(a)hotmail.com> --- In recent configurations of setting up Email, I discovered it was working correctly, but GMail was re-writing the header, because I had not authenticated the other email addresses. Log in at gmail, and then go to the following in the address bar: https://mail.google.com/mail/u/0/#settings/accounts (cog -> settings -> accounts if you wish to click the long way) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 8643] Add important constraint to marc subfields
by bugzilla-daemon＠bugs.koha-community.org 08 Aug '17

08 Aug '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8643 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #38 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- There are some things odd about this patch set: 1) In the database update the new columns are added in different spots: +ALTER TABLE marc_subfield_structure ADD COLUMN important TINYINT(4) NOT NULL DEFAULT 0 AFTER mandatory; +ALTER TABLE marc_tag_structure ADD COLUMN important TINYINT(4) NOT NULL DEFAULT 0 AFTER frameworkcode; Why not have marc_tag_structure.important after mandatory too? This is mostly cosmetic, but I was wondering about the inconsistency. 2) There is a change on the serialitems table in kohastructure.sql, that needs to be removed from this patch set: @@ -2456,7 +2458,7 @@ DROP TABLE IF EXISTS `serialitems`; CREATE TABLE `serialitems` ( `itemnumber` int(11) NOT NULL, `serialid` int(11) NOT NULL, - PRIMARY KEY (`itemnumber`), + UNIQUE KEY `serialitemsidx` (`itemnumber`), 3) In marctagstructure.tt the following line is added, I think also accidentally? + <li><label for="authorised_value">Authorized value: </label>[% authorised_value %] (if you select a value here, the indicators will be limited to the authorized value list)</li> Also, when testing I noticed that the important field shows up below the authorised value. I think it should be right below mandatory here too, to be consistent with the subfield configuration. 4) The number of the tab is missing from the alert: A few important fields are not filled: * tag 245 subfield b Zusatz zum Titel in tab Are you sure you want to save? 5) The hightlighting seems to only work for subfields, not for fields, is that correct? I think it would be nice if the important fields highlighted in a different color to the mandatory ones (totally not blocker). -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11317] Add a way to access files from the intranet
by bugzilla-daemon＠bugs.koha-community.org 08 Aug '17

08 Aug '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11317 --- Comment #81 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Created attachment 65691 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=65691&action=ed… Bug 11317 - Follow-up - Fixing merge error and cosmetic changes - Fixed conflicts on reports-home.tt from adding/removing the link before moving it to tools - Slightly reworded second line on the tools page to be a bit more verbose. - Added entry to the tools-menu.inc. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11317] Add a way to access files from the intranet
by bugzilla-daemon＠bugs.koha-community.org 08 Aug '17

08 Aug '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11317 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #80 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I am testing with a kohadevbox, but have problems to access the file, even though it is listed on the page. This is what I did: - Added the entry to koha-conf.xml, copied from the plugins/uploads default <accessdir>/var/lib/koha/kohadev/files</accessdir> - Created a file with runreport.pl and moved it to the files directory - The file is listed on the tool page - When I try to access the file, I get "internal server error" - The Plack error log shows: /home/vagrant/kohaclone/tools/access_files.pl line 119. I thought it might be permission related, but even with 777 the problem remains: -rwxrwxrwx 1 kohadev-koha kohadev-koha 592 Aug 8 2017 report1.csv While testing I've made a few little changes: - Fixed conflicts on reports-home.tt from adding/removing the link before moving it to tools - Slightly reworded second line on the tools page to be a bit more verbose. - Added entry to the tools-menu.inc. Attaching this as a follow-up for sign-off if you agree. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13374] AllowHoldsOnPatronsPossessions not working
by bugzilla-daemon＠bugs.koha-community.org 08 Aug '17

08 Aug '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13374 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |In Discussion --- Comment #8 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Kyle, I think a new bug report must be opened, the original issue seems fixed. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11299] Add a button to automatically link authority records in cataloguing (AJAX )
by bugzilla-daemon＠bugs.koha-community.org 08 Aug '17

08 Aug '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11299 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #41 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Argh, sorry, I think I forgot to switch the status last time I worked on this. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12095] Hold queue should take closed dates into account
by bugzilla-daemon＠bugs.koha-community.org 08 Aug '17

08 Aug '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12095 jdemuth(a)roseville.ca.us <jdemuth(a)roseville.ca.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jdemuth(a)roseville.ca.us -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8643] Add important constraint to marc subfields
by bugzilla-daemon＠bugs.koha-community.org 08 Aug '17

08 Aug '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8643 Philippe Audet-Fortin <philippe.audet-fortin(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60554|0 |1 is obsolete| | --- Comment #37 from Philippe Audet-Fortin <philippe.audet-fortin(a)inlibro.com> --- Created attachment 65682 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=65682&action=ed… Bug 8643 - Add important constraint to marc subfields This fix permits to add an "Important" option to the marc structure pages. Testing: I Apply the patch II Run updatedatabase.pl 0) Define 100 as an "important" field ( Administration » MARC bibliographic framework » MARC structure ( Default Frameword) » Edit ) 1) Define 100$a as an "important" subfield (Administration » MARC bibliographic framework » MARC structure (Default Frameword) » Subfield » Onglet a) 2) Edit a record to clear the field 100 3) Save the record. 4) Validate the following message: A few important fields are not filled: * tag 100 subfield a Nom de personne in tab * Field 100 is important, at least one of its subfields should be filled. Are you sure you want to save? sponsored by the CCSR ( http://www.ccsr.qc.ca ) Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel(a)gmail.com> Work as described. Fixed small conflict -- You are receiving this mail because: You are watching all bug changes.

1 0