January 2010 - Koha-bugs - lists.koha-community.org

[Bug 3798] New: change branch of request fail
by bugzilla-daemon＠kohaorg.ec2.liblime.com 30 Apr '10

30 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3798 Summary: change branch of request fail Product: Koha Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: nahuel.angelinetti(a)biblibre.com ReportedBy: nahuel.angelinetti(a)biblibre.com Estimated Hours: 0.0 Change sponsored?: --- Branchcode not specified in templates, so modification cannot be saved. -- 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 2

[Bug 3881] New: No Page for Opac Privacy
by bugzilla-daemon＠kohaorg.ec2.liblime.com 30 Apr '10

30 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3881 Summary: No Page for Opac Privacy Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: critical Priority: P5 Component: OPAC AssignedTo: paul.poulain(a)biblibre.com ReportedBy: nengard(a)gmail.com CC: wizzyrea(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- There should be a page in the OPAC that lets the user set his/her privacy settings - but when OpacPrivacy is on or off the OPAC display is the same ... no options for the patron. On looking at the patch it looks like only the DB change was submitted - not the new page. ------------ Nicole Engard a écrit : Hello all, Liz Rea and I were looking at the newest version of HEAD and see the system preference for OpacPrivacy, but turning it on doesn't seem to do anything. I did some searching through the patches and only see the patch where the preference was added - but can't find anything else. Can someone tell us how this is supposed to work? yes, me, as I wrote the feature. You're supposed to have a new page on opac, that let the user control the behaviour he want (ie: anonymize immediatly, let library choose, never anonymize my reading list) and the anonymiser script has been modified accordingly (as well as the return.pl script, to anonymize immediatly if requested) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 -- 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 8

[Bug 3619] New: C4::Letters::_send_message_by_email does not obey AutoEmailPrimaryAddress
by bugzilla-daemon＠kohaorg.ec2.liblime.com 30 Apr '10

30 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3619 Summary: C4::Letters::_send_message_by_email does not obey AutoEmailPrimaryAddress Product: Koha Version: HEAD Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P3 Component: Architecture, internals, and plumbing AssignedTo: dbavousett(a)ptfs.com ReportedBy: dbavousett(a)ptfs.com Estimated Hours: 0.0 Change sponsored?: --- Customer set AutoEmailPrimaryAddress to "emailpro", then populated emailpro, thinking that notices would then go to the email address specified in that field. However, C4::Letters::_send_message_by_email is only capable of using the email field. This enhancement would cause C4::Letters::_send_message_by_email to obey the syspref. This is an interim solution; the long-term Right Thing would probably be to create a syspref (or modify the existing one) to allow for a library-selectable hierarchy--a list of potential email address fields to use. I therefore suggest leaving this bug ASSIGNED, until the better solution can be implemented. Patch forthcoming shortly. -- 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 3482] New: Print overdue and hold notices for patrons without email addresses
by bugzilla-daemon＠liblime.com 29 Apr '10

29 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3482 Summary: Print overdue and hold notices for patrons without email addresses Product: Koha Version: rel_3_0 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: enhancement Priority: P5 Component: Notices AssignedTo: henridamien(a)koha-fr.org ReportedBy: jwagner(a)ptfs.com Estimated Hours: 0.0 Change sponsored?: Sponsored Sponsored by East Brunswick Public Library, East Brunswick, NJ, USA. If a patron does not have an email address for overdue or hold notices, an html file is generated in a specified directory which can be opened/downloaded by library staff. The notice file can be formatted to match Z mailers or other mailer layouts. The html file is set up to obey the notice file formatting and spacing, and to insert a page break between notices for printing. The overdues.pl script was modified to allow printing overdues to a specified path and file. A new script was added to collect hold notices and send to a specified path. Print overdues use the same notice file as emailed overdues; print holds require a new notice file named HOLD_PRINT. -- 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 6

[Bug 3521] New: Items table in catalogue/detail.pl and cataloguing/additem.pl is sorted nonsensically
by bugzilla-daemon＠liblime.com 28 Apr '10

28 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3521 Summary: Items table in catalogue/detail.pl and cataloguing/additem.pl is sorted nonsensically Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: wizzyrea(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- The items in the table for catalogue/detail.pl and cataloguing/additem.pl are sorted by database addition date. This is nonsensical in large consortia/migrated systems. There are a couple of different ways to handle this: 1. Sort by logged in user branch first (makes most sense to us) 1a. There has been some discussion of "sort by logged in user" as a system preference across the board for all places such a sort would make things easier (adding patrons, etc). 1b. It would be nice if it sorted by logged in user, then by acquisition date, not date item added to the database. In migrated collections, database add date is always the date of migration into the system, and this results in a nonsensical display. 2. Add a tablesorter or some other jquery hackery to sort by any column. Other solutions and comments are welcome. -- 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 6

[Bug 3477] New: Store patron OPAC passwords in plain text
by bugzilla-daemon＠liblime.com 28 Apr '10

28 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3477 Summary: Store patron OPAC passwords in plain text Product: Koha Version: rel_3_0 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: enhancement Priority: P5 Component: Patrons AssignedTo: gmcharlt(a)gmail.com ReportedBy: jwagner(a)ptfs.com Estimated Hours: 0.0 Change sponsored?: Sponsored Sponsored by East Brunswick Public Library, East Brunswick, NJ, USA. Library staff wanted to be able to see patron passwords when patrons forget the password and ask. Created a system preference StorePasswordPlaintext and a new borrowers table column named password_plaintext. For non-staff accounts, the current password will appear in the Change Password box on member-password.pl. The code will not display staff account passwords. Plaintext passwords can only be stored for patrons added or patron passwords edited after the syspref is turned on; it cannot retroactively convert existing passwords. Thus, if this capability is desired, the feature must be present and the syspref turned on before patron import. Libraries should consider the security implications of having plaintext passwords visible. -- 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 3435] New: Support 3M smart chute extensions
by bugzilla-daemon＠liblime.com 27 Apr '10

27 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3435 Summary: Support 3M smart chute extensions Product: Koha Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: SIP2 AssignedTo: joe.atzberger(a)liblime.com ReportedBy: galen.charlton(a)liblime.com Estimated Hours: 0.0 Change sponsored?: Sponsored At the request of the Northeast Kansas Library system, we're enhancing the SIP2 server to return additional information to support the 3M Smart Chute devies. -- 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 3

[Bug 3503] New: Automatic rollover of patron category codes based on birth date
by bugzilla-daemon＠liblime.com 27 Apr '10

27 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3503 Summary: Automatic rollover of patron category codes based on birth date Product: Koha Version: rel_3_0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Patrons AssignedTo: gmcharlt(a)gmail.com ReportedBy: beverly.church(a)liblime.com Estimated Hours: 0.0 Change sponsored?: --- For those libraries with patron categories based on age, it would help to have these codes automatically changed based on the patron's birth date. The patron category code has the minimum and maximum age. However, it's missing a field where the library can enter the "rollover" code which needs to be entered in the patron record once the patron has exceeded the maximum age for his/her current category. -- 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 6

[Bug 3792] New: Checking out on-hold item to someone else replaces item-level hold with next available
by bugzilla-daemon＠kohaorg.ec2.liblime.com 27 Apr '10

27 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3792 Summary: Checking out on-hold item to someone else replaces item- level hold with next available Product: Koha Version: rel_3_0 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P3 Component: Hold requests AssignedTo: gmcharlt(a)gmail.com ReportedBy: jwagner(a)ptfs.com Estimated Hours: 0.0 Change sponsored?: --- Here's the scenario. A patron places an item-level hold on a particular copy of a title and is first in line (priority 1). Another patron brings that particular item up to the desk and wants to check it out; library policy allows that even though it's on hold for other people. When the item is checked out, the screen warns that it's on hold for patron A and do you want to proceed with the checkout. If you click Yes, the item is checked out, but the item-level hold for patron A is now replaced by a "next available" hold. I replicated this on latest Koha head. The system should retain the item-level link when putting Patron A back in the holds queue. This may be related to the problem described in Bug 2830 -- it's not the same problem, but that's the only similar report I found. Any ideas on how to fix? -- 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 3567] New: Display Alternate Graphic Representation (MARC21 880) in OPAC
by bugzilla-daemon＠kohaorg.ec2.liblime.com 23 Apr '10

23 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3567 Summary: Display Alternate Graphic Representation (MARC21 880) in OPAC Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: wolfgang.heymans(a)bsz-bw.de ReportedBy: wolfgang.heymans(a)bsz-bw.de CC: katrin.fischer(a)bsz-bw.de Estimated Hours: 0.0 Change sponsored?: --- Extend XSL template for OPAC detail and results to display MARC21 fields 880 containing Alternate Graphic Representation for title, author et al. Fields in right-to-left languages like Hebrew will be displayed floating right to their latin counterparts, fields in left-to-right scripts like Cyrillic together with the latin ones. Example: MARC21 record =245 10$6880-02$aSidur tefilah Tselota de-Avraham :$bʻal pi nusaḥ ṿe-seder she-hitpalel ... Avraham ... Landa ... /$cmevorar ʻa. p. ha-halakhah ṿeha-Ḳabalah ʻa. y. ... Menaḥem Mendil Ḥayim ... Landa ṿe-nikra shemo Shomeʻa tefilah ... ; ṿa-ʻalehem nilṿah Sheruta di-tselota, heʻarot, heʾarot u-meḳorot li-tefilah u-minhageha ba-halakhah, be-agadah uve-Ḳabalah me-et Yaʻakov b.k.R. Yiśraʾel Ḥanokh Ṿerdiger. =260 \\$6880-03$a[Ḥ.m. :$bḥ. mo. l.,$c716]-<753 > [1956-<1992 >]$e(Tel Aviv :$fDefus "Grafiḳah") =300 \\$av. <1-5 > ;$c25 cm. =500 \\$aCover title: Sidur Tselota de-Avraham. =500 \\$aVol. 3-5 edited by Avraham Ṿerdiger. =500 \\$aVol. 2 published: [Jerusalem?] : Ṿaʻad le-hotsaʾat ha-sidur Tselota de-Avraham; v. 3-5 published: Yerushalayim : Gal-ʻEd. =500 \\$aAshkenazic and Sephardic rites are included. =500 \\$aVol. 3-4 also numbered 1-2. =505 1\$aḥeleḳ 1. Mekhil tefilat Shaḥarit shel ḥol u-Musaf shel rosh ḥodesh -- ḥeleḳ 2. [without special title] -- ḥeleḳ 3. ʻAl ʻinyene Shabat ḳodesh ṿe-sidur tefilah le-lel Shabat ḳodesh -- ḥeleḳ 4. Sidur tefilah le-lel Shabat ḳodesh -- ḥeleḳ 5. Sidur tefilah le-yom Shabat ḳodesh ṿe-ʻinyene Shabat ḳodesh. =650 \0$aSiddurim$xTexts. =650 \0$aJudaism$xLiturgy$xTexts. =650 \0$aJudaism$xSephardic rite$xLiturgy$xTexts. =630 00$6880-04$aSiddur. =700 1\$6880-05$aLandau, Abraham ben Raphael,$d1789-1875. =700 0\$6880-06$aMenaḥem Mendil Ḥayim,$ca.b.d. ḳ.ḳ. Zaṿyertsye. =700 1\$6880-07$aṾerdiger, Yaʻaḳov ben Yiśraʾel Ḥanokh,$d1901-1981. =700 1\$6880-08$aṾerdiger, Avraham. =730 02$aSiddur (Sephardic).$f1956. =740 0\$6880-09$aTselota de-Avraham. =740 0\$6880-10$aSidur Tselota de-Avraham. =740 0\$6880-11$aShomeʻa tefilah. =740 0\$6880-12$aSheruta di-tselota. =880 0\$6130-01/(2/r$aסדור. =880 10$6245-02/(2/r$aסדור תפלה צלותא דאברהם :$bעל פי נוסח וסדר שהתפלל ... אברהם ... לנדא ... /$cמבורר ע״פ ההלכה והקבלה ע״י ... מנחם מנדיל חיים ... לנדא ונקרא שמו שומע תפלה ... ; ועליהם נלוה שירותא דצלותא, הערות, הארות ומקורות לתפלה ומנהגיה בהלכה, באגדה ובקבלה מאת יעקב בכ״ר ישראל חנוך ורדיגר. =880 \\$6260-03/(2/r$a[ח״מ :$bחמו״ל,$c> [716]-<753 > [1956-<1992$e(תל אביב :$fדפוס ״גרפיקה) =880 04$6630-04/(2/r$aסדור. =880 1\$6700-05/(2/r$aלנדא, אברהם. =880 1\$6700-06/(2/r$aלנדא, מנחם מנדיל חיים. =880 1\$6700-07/(2/r$aורדיגר, יעקב בן ישראל חנוך. =880 1\$6700-08/(2/r$aורדיגר, אברהם. =880 0\$6740-09/(2/r$aצלותא דאברהם. =880 0\$6740-10/(2/r$aסדור צלותא דאברהם. =880 0\$6740-00/(2/r$aסידור תפלה צלותא דאברהם. =880 0\$6740-00/(2/r$aסידור צלותא דאברהם. =880 0\$6740-11/(2/r$aשומע תפלה. =880 0\$6740-12/(2/r$aשירותא דצלותא. -- 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 13