May 2018 - Koha-bugs - lists.koha-community.org

[Bug 10306] Koha to MARC mappings (Part 1): Allow multiple mappings per kohafield (for say 260/RDA 264)
by bugzilla-daemon＠bugs.koha-community.org 14 May '18

14 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 --- Comment #85 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Agnes Rivers-Moore from comment #84) > I would like to request that the method for setting this up is documented in > some detail for the end user. Many smaller libraries stay well away from > mapping & frameworks for fear of breaking something so we are not familiar > with making adjustments. If the frameworks can be adjusted/new ones set up > set up during upgrade that would be nice. This is a very tiny and easy adjustment: Go to Administration/Koha to MARC mapping. For MARC21, find the table row for biblio.copyrightdate (260c), and click on Add. Type 264,c in the popup. Click OK. You're done. Note: At this point new or edited records with 264c, will adjust copyrightdate. Unchanged records will not. A sysadmin may run the script misc/maintenance/touch_all_biblios --where "copyrightdate is null" for you. This would update all biblios without 260c but having a 264c. (Note: maybe IFNULL(copyrightdate,0)=0 is even better as where condition.) In view of comment83 this setting is not yet included in frameworks etc. This will be done on the follow-up reports. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12310] Decimal separators issues in patrons payments/fines
by bugzilla-daemon＠bugs.koha-community.org 14 May '18

14 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12310 --- Comment #90 from Victor Grousset/tuxayo <victor.grousset(a)biblibre.com> --- (In reply to Marcel de Rooy from comment #89) > (In reply to Victor Grousset/tuxayo from comment #88) > > That means that in the case of wanting to use thousands separators; > > one has to renounce having , AND . as decimal seps. > > The one that is elected as the thousands sep can't be in the > > DecimalSeparators syspref. > > Sounds better to me. Do you need more feedback? From the list ? Hopefully not, because on the IRC and mainly during the hackfest, I have collected a lot of feedback. Which caused the proposed solution to change more than 5 times. I already bothered a lot of people (from france, germany and the US) to ensure that there won't be librarian tears if this solution goes into production. ^^ Each simpler solution raised issues about existing use cases that work now or worked before the ~16.11 regression. > > > I would probably prefer to assign both roles in separate > > > preferences to resolve the ambiguity. Now we still do not know what means > > > 3,512 ? Is it three thousand or three ? > > > > Does the above explanation addresses all of your concerns? > > Can't say that yet. > > > Is there a way to better phrase the syspref text? > > Depends on the choices we will make. Do you add another pref for thousand > sep? No need for it. «Gets rid of the spaces, currency symbols, names (EUR) There is nothing specific about currency symbols is this patch. It just removes everything that is not a digit a minus or a separator.» So one can use anything as a thousands sep. As long as it's not a digit a minus or in the DecimalSeparators syspref. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12310] Decimal separators issues in patrons payments/fines
by bugzilla-daemon＠bugs.koha-community.org 14 May '18

14 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12310 --- Comment #89 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Victor Grousset/tuxayo from comment #88) > (In reply to Marcel de Rooy from comment #86) > > Reading: "So thousands separators come at the expense of handling both dots > > and commas." > > > > If I understand correctly, you do not know which separator has which > > function? > > That means that in the case of wanting to use thousands separators; > one has to renounce having , AND . as decimal seps. > The one that is elected as the thousands sep can't be in the > DecimalSeparators syspref. Sounds better to me. Do you need more feedback? From the list ? > > I would probably prefer to assign both roles in separate > > preferences to resolve the ambiguity. Now we still do not know what means > > 3,512 ? Is it three thousand or three ? > > Does the above explanation addresses all of your concerns? Can't say that yet. > Is there a way to better phrase the syspref text? Depends on the choices we will make. Do you add another pref for thousand sep? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 19637] New: jsPrintSetup not supported in Firefox Quantum
by bugzilla-daemon＠bugs.koha-community.org 12 May '18

12 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19637 Bug ID: 19637 Summary: jsPrintSetup not supported in Firefox Quantum Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This is mainly a heads-up. As of Firefox v57 (Quantum), the addon jsPrintSetup is no longer supported. From what I've been able to tell in the bug reports this is due to missing functionality in the WebExtensions API. Relevant bug reports: Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1385827 Addon: https://github.com/edabg/jsprintsetup/issues/39 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 12310] Decimal separators issues in patrons payments/fines
by bugzilla-daemon＠bugs.koha-community.org 11 May '18

11 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12310 --- Comment #88 from Victor Grousset/tuxayo <victor.grousset(a)biblibre.com> --- (In reply to Marcel de Rooy from comment #86) > Reading: "So thousands separators come at the expense of handling both dots > and commas." > > If I understand correctly, you do not know which separator has which > function? That means that in the case of wanting to use thousands separators; one has to renounce having , AND . as decimal seps. The one that is elected as the thousands sep can't be in the DecimalSeparators syspref. > I would probably prefer to assign both roles in separate > preferences to resolve the ambiguity. Now we still do not know what means > 3,512 ? Is it three thousand or three ? Does the above explanation addresses all of your concerns? Is there a way to better phrase the syspref text? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12310] Decimal separators issues in patrons payments/fines
by bugzilla-daemon＠bugs.koha-community.org 11 May '18

11 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12310 --- Comment #87 from Victor Grousset/tuxayo <victor.grousset(a)biblibre.com> --- (In reply to Koha Team Lyon 3 from comment #85) > When you choose to pay or to write off a fine, you arrive on paycollect.pl : > there, the amounts are displayed with a dot. Indeed that's not very consistent and confusing. We could hide the processed value in a hidden field but that might not be clean and could lead to other issues. (in follow-up BZ I hope) > If you don't change anything, > the dot is considered as a decimal separator. If you want to change the > amount without changing the separator which is already displayed, it will > not be consider. > for example : > '500.00' is displayed > You change it on '1.00' > It will be transform in '100' That's not great :( > It's consistent with your DecimalSeparators syspref but quite confusing. > > At least, it would be great to have on paycollect the same help we can find > mancredit ou maninvoice (Example: 5,12). > By the way, this help only figures the first character of the > DecimalSeparators syspref which is not completely right : > DecimalSeparators = ., > You will see : "Example: 5.12" > > DecimalSeparators = ,. > You will see : "Example: 5,12" That's still a valid example, which is the point of the help. But I agree get that there is something not optimal there. > > But as it is, the patches handle the main issue, +1 > so I hope it could be in > the 18.05 release ! We're too, late. At least, that leaves time to find remaining bugs or submit follow ups. -- 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 11 May '18

11 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11299 --- Comment #73 from Blou <philippe.blouin(a)inlibro.com> --- 1) Did you read my explanation on the matter of answering? The user/owner has many other priorities, and the delay should not be a consideration. Who's waiting on who here? 2) In all those exchanges, I do not see the issue of Tests being raised until you did. Not that it's not valid, mind you, but the testers are working on the Functionalities/usage (Kathleen) or questioning the validity (Marcel). I prefer that, personally. No point in working and rebasing and working again on tests for a feature that might not get accepted as deemed useless. Tests are easy, Bouzid/team has written plenty of those for all the other patches. I have no personal attachment to the feature. Didn't code it, do not maintain it. And knowing what code it touches, it matters to me that it's done well. The process is important and must be followed. But the feature, per the actual cataloging users, is a must have for a serious tool. Must. Have. Philippe PS You get a piece of meat, you smell it, your experience/intuition tells you it's shit, you won't eat it. No need to call a biolab to test the meat. QAs have seen enough features and pieces of code to do that with patches. I do that with all _new_ features or bugs we talk about submitting. Let me tell you I have a picky nose myself, and I'm good at math/finance. The paying users appreciate. A smell test is not an insult. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14302] Remove GRS1 indexing related code
by bugzilla-daemon＠bugs.koha-community.org 11 May '18

11 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14302 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rel_18_05_candidate | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11943] Koha::Virtualshelfshare duplicates rows for the same list
by bugzilla-daemon＠bugs.koha-community.org 11 May '18

11 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11943 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |20754 See Also|https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=20754 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20754 [Bug 20754] Does table virtualshelfshares need a unique index on shelfnumber+borrowernumber+invitekey? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7910] Batch renewal of subscriptions
by bugzilla-daemon＠bugs.koha-community.org 11 May '18

11 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7910 --- Comment #29 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Last patch pushed to master. -- You are receiving this mail because: You are watching all bug changes.

1 0