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

[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

[Bug 11911] Purchase suggestions can be accessed by all staff members / no specific permission
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '18

01 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11911 --- Comment #20 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Created attachment 75737 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=75737&action=ed… Bug 11911: (follow-up) Hide suggestion box on acq start page if no permission When the user is not superlibrarian or has the manage_suggestions permission, the suggestion box on the left of the acq start page needs to be hidden. Signed-off-by: Séverine QUEUNE <severine.queune(a)bulac.fr> Signed-off-by: Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11911] Purchase suggestions can be accessed by all staff members / no specific permission
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '18

01 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11911 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #75630|0 |1 is obsolete| | Attachment #75631|0 |1 is obsolete| | --- Comment #19 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Created attachment 75736 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=75736&action=ed… Bug 11911: Add a separate permission for managing suggestions Without this patch only catalogue permission was required for managing suggestions. This patch adds a new permission in the acquisition module do manage suggestions and updates staff user permissions accordingly. To test: - Make sure there is a pending suggestion - Create a few users with different permission sets: - User 1: only catalogue - User 2: any acquisition permission - User 3: cataloguing permission - Check all of them can access: /cgi-bin/koha/suggestion/suggestion.pl - Apply the patch - Verify all of them now have the suggestions_manage permission - Verify everything displays correctly on: - intranet start page - patron account in staff - acquisition start page - suggestion page (try to access by URL too) - Remove suggestions_manage for a staff user - Repeat tests above, access should be denied/links not visible Bonus: - Fixes the link on the acquisition start page for late orders to mage the permissions of the page itself: order_receive Signed-off-by: Séverine QUEUNE <severine.queune(a)bulac.fr> Signed-off-by: Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11911] Purchase suggestions can be accessed by all staff members / no specific permission
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '18

01 Jun '18

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

1 0

[Bug 11911] Purchase suggestions can be accessed by all staff members / no specific permission
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '18

01 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11911 --- Comment #18 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- (In reply to Jonathan Druart from comment #17) > After the require the new { acquisition => 'suggestions_manage' } they* -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11911] Purchase suggestions can be accessed by all staff members / no specific permission
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '18

01 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11911 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |release-notes-needed --- Comment #17 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- We should highlight the change in the release notes: Before: members/purchase-suggestions.pl required { borrowers => 'edit_borrowers' } suggestion/suggestion.pl required { catalogue => 1 } After the require the new { acquisition => 'suggestions_manage' } -- 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 01 Jun '18

01 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13049 --- Comment #20 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (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. -- You are receiving this mail because: You are watching all bug changes.

1 0