October 2015 - Koha-bugs - lists.koha-community.org

[Bug 6427] New: Rewrite of the accounts system
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '15

19 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6427 Bug #: 6427 Summary: Rewrite of the accounts system Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org The accounts system is in need of a rewrite. This will solve two purposes: 1) It'll make the code a lot nicer, and things won't be doing direct table access from all over the place. Also, some unused and long dead features will be stripped out. 2) It'll allow the account code to be a lot more flexible, making features like partial payments a whole lot seamless. This is in progress, it can be viewed here: http://git.catalyst.net.nz/gw?p=koha.git;a=shortlog;h=refs/heads/bywater/wr… And accessed via: git://git.catalyst.net.nz/git/public/koha.git, in the branch "bywater/wr78012" -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 795

[Bug 10306] New: acquisitions shows publisher from 260 only
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '15

19 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 Bug ID: 10306 Summary: acquisitions shows publisher from 260 only Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com The acquisitions module show publisher info from the 260, but now libraries are using RDA and need the 264 to show if there is no 260. This is easy enough on XSLT styled pages, but acquisitions is not one of those. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 14057] New: Inventory is painfully slow
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '15

19 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14057 Bug ID: 14057 Summary: Inventory is painfully slow Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: mtompset(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org While attempting to run an inventory, I attempted to run an inventory on a single barcode with no filters. It gave me a gateway timeout error. My goal is to speed it up. The major source of the problem is in C4::Item, where it attempts to replace the authorized value (e.g. 0) with a description (e.g. Lost -- these are hypothetical examples, so don't expect 0=Lost somewhere). -- You are receiving this mail because: You are watching all bug changes.

1 35

[Bug 5079] New: Make display of shelving location and call number in XSLT results controlled by sysprefs
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '15

19 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Summary: Make display of shelving location and call number in XSLT results controlled by sysprefs Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: jwagner(a)ptfs.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 The XSLT results list does not show shelving location (the non-XSLT display does). For both shelving location and call number, some sites want either/both to show, while sites with 30-40 branches may want to declutter the display. I'm proposing to add separate sysprefs to control whether or not XSLT results list displays (a) shelving location and (b) call number. Comments? Suggestions? -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 80

[Bug 14239] New: Bibframe support in Koha
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '15

19 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14239 Bug ID: 14239 Summary: Bibframe support in Koha Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This is getting asked about more and more. I thought I should open a bug for it. There is an open source tool to convert marc to bibframe we should maybe watch: https://github.com/lcnetdev/marc2bibframe -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 13548] New: "High Holds" does not behave correctly when decreaseLoanHighHoldsValue is set to 0.
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '15

18 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13548 Bug ID: 13548 Summary: "High Holds" does not behave correctly when decreaseLoanHighHoldsValue is set to 0. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Partner wants to decrease the length of loans when *any* items are checked out. Setting 'decreaseLoahHighHolds' system preferences as follows: +-------------------------------+------------+ | variable | value | +-------------------------------+------------+ | decreaseLoanHighHolds | 1 [Enable] | | decreaseLoanHighHoldsDuration | 14 | | decreaseLoanHighHoldsValue | 0 | +-------------------------------+------------+ This shows on the system preferences screen as follows: [Enable] the reduction of loan period to [14] days for items with more than [0] holds. Checking out *any* item (regardless of whether or not it has holds) will trigger the following message: High demand item. Loan period shortened to 0 days (due ). Check out anyway? According to the system preferences description, this should not be triggered unless there is at least one hold. According to the partner, if decreaseLoanHighHoldsValue is set to 1, High Holds isn't triggered until an item is checked out that has two holds placed, meaning that it's impossible to trigger at exactly 1 hold placed. when decreaseLoanHighHoldsValue is 0, the loan period is *not* shortened, even though the message pops up. The description of decreaseLoanHighHoldsDuration is also misleading: [Enable] the reduction of loan period to [decreaseLoanHighHoldsDuration] days should read [Enable] the reduction of loan period by [decreaseLoanHighHoldsDuration] days because, the loan period is not set to a constant 'decreaseLoanHighHoldsDuration' days; rather it is decremented by that amount. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 14063] New: Implement language overlay for authorised values
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '15

17 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14063 Bug ID: 14063 Summary: Implement language overlay for authorised values Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr There is an urgent need to make authorised values translatable in mulitlingual installations. For the examples I take English (en), French (FR-fr and German (de-DE). Example: OPAC (Public interface) - Set syspref 'suggestion' to: [Allow] patrons to make purchase suggestions on the OPAC. - Select English - OPAC: Log in, go to Purchase suggestions > Create a new suggesion - The dropdown "Reason for suggestion:" shows the authorised values from OPAC_SUG, e.g. "The copy on the shelf is damaged" and "Upcoming title by popular author" - Select German - The dropdown "Begründung" shows the same (English) values. Intranet (Staff client) - Go to Home > Acquisitions > Suggestions management > New purchase suggestion - Switch between languages, the dropdown "Reason for suggestion" changes the label, but the values are not ranslated. - Same with the detail view of a suggestion There are more places with similar problems. The only (poor and ugly looking) possibility is to have multilingual text in the same entry, e.g. "Damaged | Beschädigt | Abîmé" "Upcoming title by popular author | Neuer Titel eines populären Autors |Oeuvre ...." - oh, that gets very long for one line in a drop down... I propose a solution that implements a language overlay for authorised values. It is minimal invasive and can immediately be used in production. Patch follows. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 9026] New: tagging improvements
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '15

17 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9026 Priority: P5 - low Change sponsored?: --- Bug ID: 9026 Assignee: gmcharlt(a)gmail.com Summary: tagging improvements Severity: enhancement Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Tools Product: Koha I got this email and wanted to share the idea with you all: Right now, tagging works this way: 1) I'm testing tagging, so I tag a title "test" 2) I go into tag moderation and see that, yay, my tag is there waiting, so it works! 3) I can choose to approve the tag test. This means anyone can apply the term test to anything in the catalog now. Not ideal since test can mean a lot of things. Perhaps a student is just using it to mark items they're using to make a test for a project. Not a good use of tags and I won't know that they've done it because I've already approved the tag. Lost my teachable moment. 4) So I reject it, because that's my only option. But now that means I can't use it to test again in the future unless I later go in, then approve it, then use it, then reject it again. I'm just proposing a step that allows you a third option. You have a tag sitting there. You don't want to approve or reject it, you just want to make it go away in this instance. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 14911] New: Serial Subscr. and Item search: Display additional 245 subfields in search results
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '15

17 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14911 Bug ID: 14911 Summary: Serial Subscr. and Item search: Display additional 245 subfields in search results Change sponsored?: --- Product: Koha Version: 3.20 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: theod(a)lib.auth.gr QA Contact: testopia(a)bugs.koha-community.org It would be great if additional 245 subfields (for example b, c, k, n, p, s) could also be displayed in Item search results and Serial subscription results (right now only 245a is displayed under the title columns)! Some -if not all- of these subfields are essential to be shown in order to differentiate the results! It seems that this exact request has been recently solved for other result pages by changing the XSLT (see http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13381) however because the mechanism used in Item search results and Serial subscription results apparently is different (ie not using XSLTs), special care should be taken to show a 'full' 245 there as well. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 14645] New: Koha::RecordProcessor should deal with Koha::MetadataRecord objects
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '15

17 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14645 Bug ID: 14645 Summary: Koha::RecordProcessor should deal with Koha::MetadataRecord objects Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Koha::RecordProcessor is designed to apply the right filters to records, depending on the declared schema. This means that a Dummy filter named like this: Koha::Filter::$schema::Dummy is going to be applied to records, based on the $schema param. It is a smart design, but in order to use this more broadly we need to remove the ambiguity between the metadata schema (for example: MARC21, UNIMARC, DublinCore, DarwinCore, MODS, etc) and the serialization format (for example USMARC/ISO, XML, JSON, etc). This will let us make better decisions on how to apply filters to records, and also provide us with enhanced flexibility on writing filters, because MARC is not enough information, you know? :-D With that in mind, I proposed extending the Koha::MetadataRecord object (I even included the record id, which could be retrieved from the search engine so less useless processing) on bug 14639, and now propose we make Koha::RecordProcessor work on Koha::MetadataRecord objects instead of just MARC::Record objects. -- You are receiving this mail because: You are watching all bug changes.

1 8