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

[Bug 3672] New: labels of <optgroups> not translatable
by bugzilla-daemon＠kohaorg.ec2.liblime.com 23 Apr '10

23 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3672 Summary: labels of <optgroups> not translatable Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: katrin.fischer(a)bsz-bw.de Estimated Hours: 0.0 Change sponsored?: --- Created an attachment (id=1180) --> (http://bugs.koha.org/cgi-bin/bugzilla3/attachment.cgi?id=1180) Screenshot of 'sort by' in opac Labels of <optgroups> seem to be not translatable in po-files. Lists using optgroups: memberentry.pl (patron categories) resort_form.inc (sort by on OPAC results page) -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 3

[Bug 3171] New: Problem due to internationalization in label-create-template.tmpl in de-DE and possibly others
by bugzilla-daemon＠liblime.com 23 Apr '10

23 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3171 Summary: Problem due to internationalization in label-create- template.tmpl in de-DE and possibly others Product: Koha Version: rel_3_0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Label printing AssignedTo: mason.james(a)liblime.com ReportedBy: ulli.brennenstuhl(a)fs.ei.tum.de Estimated Hours: 0.0 If the form is submitted the operation parameter passed in the query is currently directly tied to the submit button in the form ( <input type="submit" name="op" value="Anlegen"> ) Because of the translations this leads to the following error, as the cgi-script expects op=Create: Can't call method "output" on an undefined value at /usr/share/koha/intranet/cgi-bin/labels/label-create-template.pl line 103, <DATA> line 275. Solution: Change the submit line to: <input type="submit" name="submit" value="Anlegen"> and add following line <input type="hidden" name="op" value="create"> This is the case for de-DE and from looking at the file the same problem should occur with the fr-FR version, but I did not investigate on the other translations Regards, Ulli Brennenstuhl -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 5

[Bug 3705] New: field 700 problem
by bugzilla-daemon＠kohaorg.ec2.liblime.com 22 Apr '10

22 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3705 Summary: field 700 problem Product: Koha Version: rel_3_0 Platform: PC OS/Version: Linux - Debian Status: NEW Severity: major Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: mah_mehidy(a)live.com Estimated Hours: 0.0 Change sponsored?: --- i have koha version 3.00.00.094 and used fields(100 & 700)to authors field(700)repeated when save for first time it save all fields good but when making editing field , all repeated fields values for field 700 are changed,the problem when making editing this is example about what is happen when save for first time it okey like this 100 $a :mohammed ahmed 100$e :author 700$a :nader galal700$e :author 700$a :sameh fahmy700$e :author 700$a:hala gamal700$e:author when editing any field(300=2C773=2C245) any field field 100 and first field 700 still good =2Cbut repeated field 700 have unknown values like this 100 $a :mohammed ahmed 100$e :author 700$a :nader galal 700$e :e-- 700$ a :e--- 700$e :e-- 700$a:ee-- 700$e:--- -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 1

[Bug 3326] New: xml entity refs display incorrectly in results page if exported and indexed as xml
by bugzilla-daemon＠liblime.com 22 Apr '10

22 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3326 Summary: xml entity refs display incorrectly in results page if exported and indexed as xml Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: galen.charlton(a)liblime.com ReportedBy: rch(a)liblime.com Estimated Hours: 0.0 Change sponsored?: --- If rebuild_zebra.pl is used with the 'as xml' switch, the XSLT processing on opac-results.pl does not handle xml entity refs properly. Symptoms: A record may display like this in search results: Standard & Poor's research insight.Report & chart library (North America) by Standard & Poor's Compustat Services. yet display correctly in the details page. Steps to reproduce: * edit a record, adding an ampersand to the title. * rebuild zebra: without -x , the title displays properly in search results. * repeat, this time running rebuild_zebra.pl -x * the '&' now displays as '&' in opac-results only. opac-details is not affected. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 7

[Bug 3154] New: OPAC Search refining by facets is wrong
by bugzilla-daemon＠liblime.com 19 Apr '10

19 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3154 Summary: OPAC Search refining by facets is wrong Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: OPAC AssignedTo: jmf(a)liblime.com ReportedBy: frederic(a)tamil.fr Estimated Hours: 0.0 OPAC facets are now generated based on current page biblio records not the whole result set. For example, if your search found 1000 records, on the first page, facets are created based on biblio record 1 to 20. Facets SHOULD be generated using Zebra facets functionnalties: http://www.indexdata.dk/zebra/doc/special-retrieval.tkl -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 9

[Bug 3293] New: XSLT Display Incorrect for MU
by bugzilla-daemon＠liblime.com 16 Apr '10

16 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3293 Summary: XSLT Display Incorrect for MU Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: nicole.engard(a)liblime.com Estimated Hours: 0.0 Change sponsored?: --- Per the comments on this document: http://koha.org/documentation/manual/3.2/opac/xslt/item-type-display Take a look at http://www.loc.gov/marc/bibliographic/bd006.html For MU (music), only codes i and j are designated as sound recordings. Codes c and d are actually "notated music" or scores. Right now a sound icon is displayed for all - making it misleading to patrons looking for sheet music. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 13

[Bug 3340] New: Enhancement for borrower loading command line
by bugzilla-daemon＠liblime.com 16 Mar '10

16 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3340 Summary: Enhancement for borrower loading command line Product: Koha Version: HEAD Platform: PC OS/Version: Windows 2000 Status: NEW Severity: enhancement Priority: P5 Component: Command-line Utilities AssignedTo: jmf(a)liblime.com ReportedBy: dschust1(a)gmail.com CC: galen.charlton(a)liblime.com Estimated Hours: 0.0 Change sponsored?: Seeking cosponsors Kohaʼs patron import tool is currently available only as a web script available in the Koha staff inter-face. Because some libraries need to be able to schedule automatic patron import runs, the patron import functionality should also be available as a command-line tool. The command-line version of the patron import tool will function in the same way as the web-based version and speciﬁcally will include the following features: • CSV patron ﬁle format • Setting match point • Setting default values for speciﬁc ﬁelds • Option to replace or add records when a match is found. • Loading of patron attribute values. David Schuster -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 5

[Bug 3312] New: automatic Borrower load Cron job
by bugzilla-daemon＠liblime.com 15 Mar '10

15 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3312 Summary: automatic Borrower load Cron job Product: Koha Version: HEAD Platform: PC OS/Version: Windows 2000 Status: NEW Severity: enhancement Priority: P5 Component: Patron Import AssignedTo: galen.charlton(a)liblime.com ReportedBy: dschust1(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- Currently I am having to load borrowers manually with the staff interface. We have setup the ability for our student management system to place files on the server. What I would like to see happen is a CRON job setup that picks up those files (currently 3 different groupings) and loads them automatically once a week. I also need some type of CRON that would also pickup the "code" files for the attributes and load that so the codes would have descriptions(teacher names) rather than the teacher ID number. Currently we are replacing most data in the borrower record except "Other name" but are replacing attributes if data is present. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 1

[Bug 3222] New: ENH: add ability to set defaut message preferences per patron category
by bugzilla-daemon＠liblime.com 11 Mar '10

11 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3222 Summary: ENH: add ability to set defaut message preferences per patron category Product: Koha Version: HEAD Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P5 Component: Patrons AssignedTo: galen.charlton(a)liblime.com ReportedBy: galen.charlton(a)liblime.com Estimated Hours: 0.0 Deadline: 2009-06-01 Change sponsored?: Sponsored Enhancement project to make the following changes to Koha's patron messaging system: [1] Add the ability to define default patron messaging preferences for each patron category. E.g., so that you can say for new patrons of category 'patron' they'll get emailed overdue notices and checkout slips by default. [2] Use the category-level default preferences to set the initial patron preferences for a new patron record, created either via the patron editing page or patron import. [3] Move the patron messaging preferences form from the messaging tab to the patron editing form in the staff interface. [4] Fix a bug to prevent a hold-filled notification from being sent multiple times; send it only the first time it is put on the hold shelf. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 8

[Bug 3397] New: Deleting item record leaves a hole in patron's reading history
by bugzilla-daemon＠liblime.com 11 Mar '10

11 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3397 Summary: Deleting item record leaves a hole in patron's reading history Product: Koha Version: HEAD Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P5 Component: Circulation AssignedTo: galen.charlton(a)liblime.com ReportedBy: mcoalwell(a)nekls.org Estimated Hours: 0.0 Change sponsored?: --- Deleted items continue to display in Fines, but disappear from the Reading History. See screen shot. Pull from deleted items table? Or pull title info from bib record? What if bib is also deleted? Not sure of the best solution. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 2