November 2019 - Koha-bugs - lists.koha-community.org

[Bug 15142] Titles facet does not work in UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '19

25 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15142 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart(a)bugs.koha-c | |ommunity.org --- Comment #7 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Should not it be removed from xsl and xml files in etc/zebradb/marc_defs/unimarc/biblios? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14741] Selecting all child permissions doesn't select the top level check box
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '19

25 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14741 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #95751|0 |1 is obsolete| | --- Comment #5 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Created attachment 95791 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=95791&action=ed… Bug 14741: Selecting all child permissions doesn't select the top level check box This patch modifies the patron flags page so that manually selecting all the child permissions also checks the checkbox for the parent permission. To test, apply the patch, open a patron record, select More -> Set permissions. - Expand a set of permissions, for instance "Add, modify, and view patron information." - If any boxes are checked, uncheck them. - Check each of the "child" checkboxes ("Add, modify, and view..." and "View patron infos..." ). - When both checkboxes are checked, the "Add, modify, and view" parent permission should be automatically checked. Signed-off-by: Maryse Simard <maryse.simard(a)inlibro.com> 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 14741] Selecting all child permissions doesn't select the top level check box
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '19

25 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14741 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 22252] New: Status messages returned by Mana are not translatable
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '19

25 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22252 Bug ID: 22252 Summary: Status messages returned by Mana are not translatable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 17047 Target Milestone: --- Some Mana messages which are shown in Koha are being passed directly from Mana as English strings: lib/Mana/Resource.pm: return { msg => "The $resource already exists on Mana, thanks for your contribution!", id => $id, statuscode => 208 }; These strings are not translatable in Koha. If each message is being sent with a unique statuscode we should put the messages strings in a template and use the statuscodes to control their display. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17047 [Bug 17047] Mana Knowledge Base : share data -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 5145] Show call number for available item in XSLT availability information
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '19

25 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5145 --- Comment #1 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- This also applies to the list view it seems. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 14680] when doing acquisitions from a staged file, MarcFieldsToOrder-syspref discounts are instead added.
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '19

25 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14680 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart(a)bugs.koha-c | |ommunity.org --- Comment #6 from Nick Clemens <nick(a)bywatersolutions.com> --- This is still valid, but I don't know if these code changes are the ones we need You can recreate this without MarcItemFieldsToOrder in fact. 1 - Stage a file 2 - Add to basket form a staged file 3 - For any of the titles check the box to add 4 - In the details set a price, replacement price, and discount 5 - Add the order 6 - ecost is set to price and rrp is the ecost plus dicsount 7 - Repeat but don't set a discount this time (and ensure bookseller has a discount set) 8 - rrp is set to price, ecost is the rrp minus the discount Why? It is from bug 7180, so ha been in place since 2014 There is much conversation on the bug, ending with: "(In reply to mathieu saby from comment #96) > To be clear : my main concern is the fact that Koha calculates a RRP price > > 20 EUR from a record with "20.00 EUR" in 010$d field. Forget the rrp value, it is not used by this patch." RRP is not really used for anything, it just says the price the vendor set, but we do have strange behaviour of sometimes the price field being the 'rrp' and sometimes being the 'ecost' I think ideally we should use the same display as when adding an order manually, so the user can choose the fields to enter, and we discount the rrp to generate ecost unless they specify. Adding some CC's here -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14636] Sorting and searching by publication year in item search doesn't work correctly
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '19

25 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14636 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |23970 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23970 [Bug 23970] itemsearch - publication date not taken into account if not used in the first field -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 24102] New: Item search: Remove leading/trailing whitespace for barcode search
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '19

25 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24102 Bug ID: 24102 Summary: Item search: Remove leading/trailing whitespace for barcode search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Item search: While for some other searches it makes sense to search for whitespace, whitespace entered in the barocde search is ususally accidental. It would be nice to remove whitespace from the search term, when the barcode search option was selected. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 14540] Move member-flags.pl to PermissionsManager to better manage permissions for testing.
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '19

25 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14540 Lari Taskula <lari.taskula(a)hypernova.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=20813 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10352] Cataloguing log search mixing itemnumber/bibnumber
by bugzilla-daemon＠bugs.koha-community.org 25 Nov '19

25 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10352 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #95785|0 |1 is obsolete| | --- Comment #18 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Created attachment 95786 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=95786&action=ed… Bug 10352: (follow-up) show the biblionumber for items in modification logs This patch adds a link to the the biblio that shows the biblionumber of the item. It makes things a little more obvious To test: 1 - Find a biblio with an item where an itemnumber on another biblio is equal to that biblionumber i.e. In the sample data: biblionumber 59 with item with itemnumber 127 item with itemnumber 59 on biblionumber 23 2 - Edit both items however you wish 3 - On biblionumber 59 click the modification log 4 - You should see "Item 127" 5 - Click "Submit" on the form - this searches as itemnumber 6 - You should see "Item 59" 7 - Apply patch 8 - On biblionumber 59 click the modification log 9 - You should see "Item 127 from Biblio 59" 10 - Click "Submit" on the form - this searches as itemnumber 11 - You should see "Item 59 from Biblio 23" 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