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

[Bug 6758] Capture membership renewal date for reporting purposes
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '18

04 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6758 Amit Gupta <amitddng135(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=20867 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12027] Shibboleth authentication for staff client
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '18

04 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12027 Ray Delahunty <r.delahunty(a)arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.delahunty(a)arts.ac.uk -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13049] Merge selfreg cron jobs into cleanup_database
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '18

04 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13049 --- Comment #21 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Katrin Fischer from comment #20) > (In reply to Marcel de Rooy from comment #19) > > (In reply to Katrin Fischer from comment #18) > > > It looks like this change introduced a regression. Before the changes it was > > > possible to define the delay for unverified registrations in hours and now > > > it's days. It will also change what actually happens when you switch over? > > > > > > With GDPR being very strict about saving data the initial feature of being > > > able to delete after x hours would be better. > > > > I think you are being even stricter now :) > > Triggered by a request from a library. I will try to submit some patches on bug 20819 this week. It now includes a (pref controlled) checkbox on opac-memberentry to give consent during selfregistration. No consent means no registration. Which makes this request less urgent again, since you will have a consent. (But note that we could already argue that it is not possible to "perform this contract" of self-registration without data. Second ground of GDPR.) -- 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 04 Jun '18

04 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12310 --- Comment #97 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Victor Grousset/tuxayo from comment #96) > I followed this example: > https://metacpan.org/pod/Number::Format#unformat_number($formatted) OK If you feel the name is good enough, keep it. No big deal. Just do not use formating, single t :) > > So thousands separators come at the expense of handling both dots and commas. > > Still opt for something that is more understandable. > I'm not sure to understand. Is the the current state the patch on this topic > acceptable? Would it be clearer if you would say that you c/should not use characters from the DecimalSeparator pref also as thousands separator? > I split the patch because the test plan was way too long. > http://irc.koha-community.org/koha/2018-03-30#i_2024887 > http://irc.koha-community.org/koha/2018-03-30#i_2024900 > > When this bug and bug 18723[1] will be in master there won't be more > fragmentation than today. > And less actually. > > locally: acquisitions and payments/fines will be internally less fragmented. > as there are currently different behaviors in *successive pages* [2] > globally: the new approach replaces an existing one (I checked that it not > used elsewhere) > see moneyFormat function. > > https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=75127&action=di… > > So, are these changes a step in the right direct worth of begin integrated? > TODO wait answer, blocking question Well, I just hope so. But willing to follow your argument. Feel free to submit the tiny adjustments you intend to, and I will try to finish here. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15505] Mark Hold Items 'On hold' instead of 'Available'
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '18

01 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15505 --- Comment #8 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to George Williams (NEKLS) from comment #7) > Working in a large consortium, I definitely want something like this. > > If a patron looks at the OPAC and sees a title with 30 items spread around > at different locations and 20 are already checked out and there are 15 > unfilled requests on the remaining 10 items the existing message can be > confusing if you're not at a branch where a copy is actually available to be > grabbed off of the shelf. > > Maybe the issue could be resolved by allowing for the wording of the wording > of the "Pending hold" message to be customized to suit the needs of the > library. If the message that displays when there is a pending hold on an > item could be tied to an authorised value, then each library could customize > the description of the item's availability in the staff client and the OPAC > to suit the needs of their library. If, for example, I want an item that is > hold_fill_targets to display a message that the item has a hold on it then I > can change the authorised value to read "Pending hold" but if I want it to > display the same availability as any other item on the shelf, I could change > the authorised value to read "Available." > > George I agree with George. This feature is needed, yet, we need to do it in a way that won't jeopardize how some libraries already use it. If it can be setup in a way we can tailor it, that would be great. Christopher -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15184] Ability to duplicate existing order lines to create a new basket
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '18

01 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15184 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |In Discussion --- Comment #3 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- We can imagine 1. You are on the vendor view (/acqui/supplier.pl?booksellerid=X), click on "New > Duplicate a basket", then you select the order lines you want to duplicate. or 2. You are on the basket view (/acqui/basket.pl?basketno=X), click "Add to basket > From existing order lines" Then you get a form/table like the one we have to search order lines (acqui/histsearch.pl), then you select the ones you want to duplicate. In both case we will have another view to change the values you want to modify. We could also: 3. You are viewing an existing basket, you click on a "duplicate" link next to one of the orders. Then you select another basket in a list. That sounds less flexible, but could be implemented later -- 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 01 Jun '18

01 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12310 --- Comment #96 from Victor Grousset/tuxayo <victor.grousset(a)biblibre.com> --- (In reply to Marcel de Rooy from comment #95) > Very brave to take this upon you ! Thanks Marcel :) > Tiny suggestion: > .decimal-unformating > Fix spelling please. At least t => tt Indeed >< thanks for catching this. QA++ :) TODO implement > but what is decimal unformat btw? I followed this example: https://metacpan.org/pod/Number::Format#unformat_number($formatted) > Better name? Something with normalize or so?? .number-normalizing .number-normalizer .number-normalize .decimal-normalizing .decimal-normalizer .decimal-normalize Which one would be good enough? TODO wait answer, blocking question > I have the feeling that DecimalSeparators and CurrencyFormat don't really > harmonize. And yes, I can understand how problematic making changes in this > area must be.. > > So thousands separators come at the expense of handling both dots and commas. > Still opt for something that is more understandable. I'm not sure to understand. Is the the current state the patch on this topic acceptable? > The number of changes to be expected here would be much larger. You actually > use the new js formatting in three acq templates. > What about things like: > [...] > And this is just to name a few; the list could probably be larger when > searching harder. > It might be impossible to make global changes but the risk of this is adding > just another approach in a few places and leaving Koha even more fragmented > on the subject? I split the patch because the test plan was way too long. http://irc.koha-community.org/koha/2018-03-30#i_2024887 http://irc.koha-community.org/koha/2018-03-30#i_2024900 When this bug and bug 18723[1] will be in master there won't be more fragmentation than today. And less actually. locally: acquisitions and payments/fines will be internally less fragmented. as there are currently different behaviors in *successive pages* [2] globally: the new approach replaces an existing one (I checked that it not used elsewhere) see moneyFormat function. https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=75127&action=di… So, are these changes a step in the right direct worth of begin integrated? TODO wait answer, blocking question [1] which will also apply these changes to aqbudgetperiods.tt aqbudgets.tt in addition of the pages concerned by the bug description. [2] a big reason of why I get the most requests to fix decimal sep issues in these views -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15184] Ability to duplicate existing order lines to create a new basket
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '18

01 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15184 --- Comment #2 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Do we want to create a new basket by duplicating order lines from only one basket, or from several baskets? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15505] Mark Hold Items 'On hold' instead of 'Available'
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '18

01 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15505 --- Comment #7 from George Williams (NEKLS) <george(a)nekls.org> --- Working in a large consortium, I definitely want something like this. If a patron looks at the OPAC and sees a title with 30 items spread around at different locations and 20 are already checked out and there are 15 unfilled requests on the remaining 10 items the existing message can be confusing if you're not at a branch where a copy is actually available to be grabbed off of the shelf. Maybe the issue could be resolved by allowing for the wording of the wording of the "Pending hold" message to be customized to suit the needs of the library. If the message that displays when there is a pending hold on an item could be tied to an authorised value, then each library could customize the description of the item's availability in the staff client and the OPAC to suit the needs of their library. If, for example, I want an item that is hold_fill_targets to display a message that the item has a hold on it then I can change the authorised value to read "Pending hold" but if I want it to display the same availability as any other item on the shelf, I could change the authorised value to read "Available." George -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14377] Indicate that a record is suppressed in staff client
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '18

01 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14377 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |20846 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20846 [Bug 20846] Suppressed Records Still Appear in Public Lists -- You are receiving this mail because: You are watching all bug changes.

1 0