May 2008 - Koha-bugs - lists.koha-community.org

[Bug 2170] Adding 'edititems' user-permission
by bugzilla-daemon＠pippin.metavore.com 27 May '08

27 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2170 ------- Comment #1 from mason.loves.sushi(a)gmail.com 2008-05-27 09:13 ------- Created an attachment (id=276) --> (http://bugs.koha.org/cgi-bin/bugzilla/attachment.cgi?id=276&action=view) functional example of both 'editcatalogue' and 'edititems' user-perms ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2170] New: Adding 'edititems' user-permission
by bugzilla-daemon＠pippin.metavore.com 27 May '08

27 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2170 Summary: Adding 'edititems' user-permission Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: Authentication AssignedTo: chris(a)bigballofwax.co.nz ReportedBy: mason.loves.sushi(a)gmail.com QAContact: koha-bugs(a)lists.koha.org This mod basically splits the existing 'edit-catalogue' user-permission into 2 permissions ('edit-catalogue' and 'edititems') ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2132] Sys Pref Column too Wide
by bugzilla-daemon＠pippin.metavore.com 27 May '08

27 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2132 ------- Comment #3 from nicole.engard(a)liblime.com 2008-05-27 05:49 ------- 60 is okay - and I'll add a suggestion to the manual that you always use Koha in 1024x768. Nicole ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2132] Sys Pref Column too Wide
by bugzilla-daemon＠pippin.metavore.com 27 May '08

27 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2132 ------- Comment #2 from oleonard(a)myacpl.org 2008-05-27 05:44 ------- There's already code in systempreferences.pl to cut off the system pref value output at 100 characters, but that's not enough if it's one long string without line breaks. Reducing that to 60 looks like it would make things fit on a 1024x768 screen. To get it to fit on 800x600 we'd have to cut it down to below 34 characters. I vote for at least 60. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2169] New: Paying only partial fines
by bugzilla-daemon＠pippin.metavore.com 27 May '08

27 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2169 Summary: Paying only partial fines Product: Koha Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: Circulation AssignedTo: galen.charlton(a)liblime.com ReportedBy: nicole.engard(a)liblime.com QAContact: koha-bugs(a)lists.koha.org For fines what if you don't want to pay the full amount? You owe $10 you want to pay $5 today. I know I can do the a credit, but that doesn't apply it to the item number * OL: Fines in general need to be gone over with a fine-toothed comb. NPL has never been able to use Koha's fines management because of flakiness like that. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2168] New: RSS feed at OPAC donot return ALL the query results but only 20 of them
by bugzilla-daemon＠pippin.metavore.com 26 May '08

26 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2168 Summary: RSS feed at OPAC donot return ALL the query results but only 20 of them Product: Koha Version: rel_3_0 Platform: PC OS/Version: All Status: NEW Severity: minor Priority: P3 Component: OPAC AssignedTo: jmf(a)liblime.com ReportedBy: henridamien(a)koha-fr.org QAContact: koha-bugs(a)lists.koha.org Seems that now, RSS feed is limited to 20 biblios, I think it is good to limit returned results. But how will the system return newcoming elements if result search are filtered ? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1850] Circ stats does not generally save ITYPE info for renewals / returns
by bugzilla-daemon＠pippin.metavore.com 26 May '08

26 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1850 rch(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |PATCH-Sent ------- Comment #2 from rch(a)liblime.com 2008-05-25 23:54 ------- Added renewals to circ stats report, added item type to stats table. An entry is still created in statistics whether or not a checkin had any effect (other than updating datelastseen). Not sure if this should be correct behavior (I think probably not), but left as is. So 'returns' statistics give you the number of times an item was submitted to returns.pl. issues and renewals give useful stats as expected, though. Darrell, can you verify the table is populated as expected after this patch is applied ? ( http://lists.koha.org/pipermail/koha-patches/2008-May/000546.html ) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2167] New: URL handling in staff client inconsistent
by bugzilla-daemon＠pippin.metavore.com 25 May '08

25 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2167 Summary: URL handling in staff client inconsistent Product: Koha Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P3 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: rch(a)liblime.com QAContact: koha-bugs(a)lists.koha.org This bug has a couple parts: (1) moredetail.pl gives a broken link for multiple 856's. This is due to the way repeated fields are handled for kohafields: if you have multiple 856's (and 856$u is linked to biblioitems.url by default), the url's are joined with '|' in biblioitems.url, giving a broken hyperlink when this field from GetBiblioData is used in moredetail.pl My suggestion is to simply remove the url display from moredetail.pl. I otherwise punt on proper handling of biblioitems.url . My inclination is to not link it in the framework and not use it. Online resources are only going to become more plentiful in metadata... Which makes (2) more important... (2) URLs aren't displayed in normal view. I think the same display mechanism for the opac should be repeated here. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1945] URLLinkText does not appear to do anything
by bugzilla-daemon＠pippin.metavore.com 24 May '08

24 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1945 rch(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor Priority|P3 |PATCH-Sent ------- Comment #2 from rch(a)liblime.com 2008-05-24 12:37 ------- Patch sent for HTML::Template display. This still needs to be handled for the xslt display. (Or we need to specify that it doesn't work with xslt). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2159] After creating a public list it doesn't appear under the lists button
by bugzilla-daemon＠pippin.metavore.com 23 May '08

23 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2159 ------- Comment #2 from oleonard(a)myacpl.org 2008-05-23 12:23 ------- A couple of options off the top of my head: - Have the lists popup use AJAX to retrieve the list titles. Then every time the menu is opened you get fresh listings. Slower, though, and I don't know whether that conflicts with the session-related things going on with lits. - Update the lists contents via javascript as part of the process of closing the popup. The lists are written in the HTML and hidden by default, so they're in the DOM available for manipulation. This sounds doable, as long as the trigger for the change happens after the list is successfully created. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0