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

[Bug 7936] New: general ticket for 3.8 help file updates
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '12

21 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7936 Priority: P5 - low Change sponsored?: --- Bug ID: 7936 Assignee: nengard(a)gmail.com Summary: general ticket for 3.8 help file updates QA Contact: koha.sekjal(a)gmail.com Severity: major Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: ASSIGNED Version: master Component: Documentation Product: Koha This is where I will put all of the patches to the 3.8 help files. -- You are receiving this mail because: You are watching all bug changes.

1 95

[Bug 5981] New: OPAC: Add limits to search history
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '12

21 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5981 Bug #: 5981 Summary: OPAC: Add limits to search history Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org Blocks: 5584 -- 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 56

[Bug 8381] New: Paging broken in OPAC search results
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '12

21 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8381 Priority: P1 - high Change sponsored?: --- Bug ID: 8381 Assignee: oleonard(a)myacpl.org Summary: Paging broken in OPAC search results Severity: critical Classification: Unclassified OS: All Reporter: jcamins(a)cpbibliography.com Hardware: All Status: NEW Version: master Component: OPAC Product: Koha The paging in the OPAC search results is now very broken: if you use the next link instead of choosing specific pages, you will be unable to get past page 2, and end up with a query string like this: /cgi-bin/koha/opac-search.pl?q=smith&offset=20&offset=40&offset=40 -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 3980] Vendor GST being ignored
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '12

21 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3980 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer(a)bsz-bw.de --- Comment #3 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- It's basically 3 levels now and even if that sounds insane, it makes sense: gist system preference vensor gst gst on order line For example in Germany you pay different taxes for serials and monographs. So if you have a vendor where you buy mostly serials, you will want to set the tax rate to another default then for a vendor you buy mostly monographs. And if you don't want to have multiple vendor entries for the same vendor and different materials, you need the order line gst. I imagine there are places where things are more simple. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 3980] Vendor GST being ignored
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '12

21 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3980 Chris Cormack <chris(a)bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris(a)bigballofwax.co.nz --- Comment #2 from Chris Cormack <chris(a)bigballofwax.co.nz> --- (In reply to comment #1) > I just ran across this today - the difference between a vendor's GST and the > syspref GIST. The behaviour I experienced was exactly similar to what is > described here. > > Additionally, if you set the vendor GST with the syspref set, no matter what > you put in the vendor (.15, 15.0) it always does .15, which if you are > trying to get 15%, is not right. > > Using the syspref GST, it's always right, and you can put in multiple > values, so I'm not sure if there's really a reason to keep the vendor > specific GST (there may be, I may just not be thinking of it). > > Thoughts? There definitely is, and the vendor GST should override the syspref. Differing places have differing sales tax, so different vendors might have different one, the syspref should be a fall back if you have set vendor charges sales tax, and don't have one set, otherwise the vendor specific one should be used. The syspref is a recent(ish) addition which has caused a regression in that vendor specified values no longer work. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 3980] Vendor GST being ignored
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '12

21 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3980 Liz Rea (CatalystIT) <liz(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |liz(a)catalyst.net.nz --- Comment #1 from Liz Rea (CatalystIT) <liz(a)catalyst.net.nz> --- I just ran across this today - the difference between a vendor's GST and the syspref GIST. The behaviour I experienced was exactly similar to what is described here. Additionally, if you set the vendor GST with the syspref set, no matter what you put in the vendor (.15, 15.0) it always does .15, which if you are trying to get 15%, is not right. Using the syspref GST, it's always right, and you can put in multiple values, so I'm not sure if there's really a reason to keep the vendor specific GST (there may be, I may just not be thinking of it). Thoughts? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 9121] New: C4::Serial SQL possible collision on subscription.subscriptionid and subscriptionhistory.subscriptionid
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '12

20 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9121 Bug ID: 9121 Summary: C4::Serial SQL possible collision on subscription.subscriptionid and subscriptionhistory.subscriptionid Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: chrish(a)catalyst.net.nz CC: colin.campbell(a)ptfs-europe.com In C4::serials a few queries use queries of the form SELECT subscription.*, subscriptionhistory.* FROM subscription LEFT JOIN subscriptionhisotry USING(subscriptionid) If there are is a subscription without a matching subscriptionhistory then this join results in subscription.subscriptionid | subscriptionhistory.subscriptionid ---------------------------------------------------------------- 1234 | NULL Once this is fetched and squashed in to a hashref (for example, via fetchall_arrayref) this will be { subscriptionid => undef } This implicitly requires that every subscription has a matching subscriptionhistory. If we change the subscriptionhistory.* to select only the parts we need then we can avoid this issue. For SearchSubscription (which is only used by serials/serials-search.pl) none of the columns from subscriptionhistory appear to be used. We could also add a 'subscription.subscriptionid' to the end of the select, but this seems less clean. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 2537] inconsistent behavior when entering tag via add button or hitting return
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '12

20 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2537 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=9120 -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 7980] New: Group search results tag input with other actions
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '12

20 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7980 Priority: P5 - low Change sponsored?: --- Bug ID: 7980 Assignee: oleonard(a)myacpl.org Summary: Group search results tag input with other actions QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: oleonard(a)myacpl.org Hardware: All Status: ASSIGNED Version: master Component: OPAC Product: Koha If TagsInputOnList in enabled there is a "new tag" form field displayed with each search result. I propose to change this so that it behaves much like the tag link at the top of search search results where clicking the link displays the form field. The per-line add tag functionality can be grouped with other "actions" (like "place hold," "add to cart," etc). Clicking the link would display the form and automatically move the focus to the entry field. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 9085] New: Installer will not run with DEBUG set
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '12

20 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9085 Priority: P5 - low Change sponsored?: --- Bug ID: 9085 Assignee: gmcharlt(a)gmail.com Summary: Installer will not run with DEBUG set Severity: major Classification: Unclassified OS: All Reporter: cnighswonger(a)foundations.edu Hardware: All Status: NEW Version: master Component: Architecture, internals, and plumbing Product: Koha This is due to raising all db errors combined with the fact that attempts to make selections from a non-existent systempreferences table raises db errors. The installer should run even with DEBUG set, otherwise dropping and recreating a development database becomes somewhat of a chore. -- You are receiving this mail because: You are watching all bug changes.

1 11