March 2013 - Koha-bugs - lists.koha-community.org

[Bug 9361] New: MARC 610 and 611 fields in bulk imports are not indexed
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '14

01 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9361 Bug ID: 9361 Summary: MARC 610 and 611 fields in bulk imports are not indexed Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: normal Priority: P4 Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: dpk(a)randomnotes.org See in 3.10.0, but may effect earlier versions as well. Import a bunch of records with 610 and 611 fields (as well as 650) (also 100, 110 and 111). Import, rebuild zebra index and then link_bibs_to_authorities. 610 and 611 entries do not get link to the appropriate authorities. The problem appears to be due to this commented code in lib/C4/Koha.pm: sub getFacets { my $facets; if ( C4::Context->preference("marcflavour") eq "UNIMARC" ) { $facets = [ ... } else { $facets = [ { idx => 'su-to', label => 'Topics', tags => [ qw/ 650a / ], sep => '--', }, # { # idx => 'su-na', # label => 'People and Organizations', # tags => [ qw/ 600a 610a 611a / ], # sep => 'a', # }, { idx => 'su-geo', label => 'Places', tags => [ qw/ 651a / ], sep => '--', }, { idx => 'su-ut', label => 'Titles', tags => [ qw/ 630a / ], sep => '--', }, Uncommenting the lines above for idx => 'su-na', followed by a rebuild of the zebra indexes (-v -b -a) and a link_bibs_to_authorities and 610s and 611s are now linked. Why was this stanza commented out? This appears to be empirically wrong. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 9110] New: GetAuthorizedHeading Can't call method "field" on an undefined
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '14

01 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9110 Bug ID: 9110 Summary: GetAuthorizedHeading Can't call method "field" on an undefined Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: matted-34813(a)mypacks.net I deleted my auth_header records; When runnong misc/link_bibs_to_authorities.pl With LinkerRelink = Do I get: GetAuthorizedheading Can't call method "field" on an undefined value at /home/koha/kohaclone/C4/AuthoritiesMarc.pm line 1191 In my case, I deleted the auth_header records, since I wanted to regenerate them. They had lots of dups since I was upgrading from a 3.0 version to (master pre-3.10). I reindexed the bibs and auths, but since I shouldn't find any auths, and though my bibs might have dangling $9 links, there might need to be a check that $record->field is viable. other settings: CatalogModuleRelink Do LinkerKeepStale = do not LinkerModule - default AutoCreateAuthorities - either setting BiblioAddsAuthorities - allow UseAuthoritiesForTracings -either setting Fuzzy not enabled. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 5706] New: Search, create lists and Export authorities from staff interface
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '14

01 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5706 Summary: Search, create lists and Export authorities from staff interface Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: MARC Authority data support AssignedTo: gmcharlt(a)gmail.com ReportedBy: eb(a)efdss.org QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 It would be useful to be able to perform certain operations on authority records in the staff interface. Specifically 1) Search by creation date 2) Search by control number 3) add to a list or create a list from a search results page 4) export MARC 5) batch edit authorities -- 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 5

[Bug 6839] New: placement of subfield 9 in 6XX and 7XX headings changes staff view
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '14

01 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6839 Bug #: 6839 Summary: placement of subfield 9 in 6XX and 7XX headings changes staff view Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: MARC Authority data support AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com We've noticed that where the subfield 9 in the 6XX and 7XX fields is first in the list of subheadings causes there to be dashes in the staff "Normal" view of the record. That subfield seems to be used to hold the link to the authority record, When a new heading is added and the record saved, making a link to the authorities, sometimes the 9 is first and sometimes second and sometimes last. But if it is first (before the a) there are dashes in front as if the subfield a were a subheading rather than a heading. The problem is that if the subfield 9 is first, while it's not pushed to the subfields loop in the GetMarc<whatever> subroutines of C4/Biblio.pm, it's still counted, and the next subfield is viewed as "second" even though it's actually first. This means a separator is put in front of it. -- 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 2

[Bug 5347] New: late order management
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '14

29 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5347 Summary: late order management Change sponsored?: Sponsored Product: Koha Version: rel_3_4 Platform: All URL: http://wiki.koha-community.org/wiki/Late_orders_acq_RF C OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: paul.poulain(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 For lateorders, we will add fields for date and comment coming from the library. For claims, we will add * a claim counter, to know how many times an order has been claimed * a claim table, containing all the claims an order has, with the date of the claim and the content of the claim -- 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 99

[Bug 5576] New: Access Koha via SSL
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '14

29 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5576 Summary: Access Koha via SSL Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P5 Component: System Administration AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 Some libraries want to access Koha over SSL. -- 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 12

[Bug 8148] New: ldap authentication should FAIL if ldap contains NEW password, and user types the PREVIOUS password
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '14

27 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8148 Priority: P5 - low Change sponsored?: --- Bug ID: 8148 CC: dpavlin(a)rot13.org Assignee: gmcharlt(a)gmail.com Summary: ldap authentication should FAIL if ldap contains NEW password, and user types the PREVIOUS password Severity: enhancement Classification: Unclassified OS: All Reporter: heupink(a)gmail.com Hardware: All Status: NEW Version: rel_3_8 Component: Authentication Product: Koha The way ldap authentication works now is that the patron password is both in ldap and in mysql, usually the primary location being ldap. If sys admins change the userpassword, it's changed directly in ldap, and koha still has the old password stored in mysql. If the user then tries to logon with the OLD password, he should get 'access denied'. But instead he/she gets in, using the old, no longer valid, password. Various possible solutions: The best one: - an option not to store the password in mysql AT ALL (passwords are very sensitive info, I would like to store them in as few places as possible) Two other solutions: - a 'flush authentication cache' button in the staff interface? - a syspref to select the order of precedence when authenticating a user? -- You are receiving this mail because: You are watching all bug changes.

1 54

[Bug 7462] New: duplicate patron shows flags
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '14

27 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7462 Bug #: 7462 Summary: duplicate patron shows flags Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha.sekjal(a)gmail.com CC: gmcharlt(a)gmail.com When you duplicate a patron record the duplicate has the patron flags showing. The patron flags should only show when editing a patron not when adding a new patron. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 9

[Bug 7237] New: duplicating patron not using patron's branch
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '14

27 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7237 Bug #: 7237 Summary: duplicating patron not using patron's branch Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: ian.walls(a)bywatersolutions.com CC: gmcharlt(a)gmail.com When duplicating a patron the branch chosen is not the branch of the patron I was duplicating but the branch I'm logged in to the staff client at. I think it should be the branch of the previous patron since I am duplicating them. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 11

[Bug 8539] New: Library transfer limits page has incorrect permission
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '14

27 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8539 Priority: P5 - low Change sponsored?: --- Bug ID: 8539 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Library transfer limits page has incorrect permission Severity: normal Classification: Unclassified OS: All Reporter: oleonard(a)myacpl.org Hardware: All Status: NEW Version: master Component: System Administration Product: Koha Permissions for branch_transfer_limits.pl are defined as "flagsrequired => {borrowers => 1}." This makes the page accessible to any user with permission to add or modify patrons. Based on the other admin scripts, the correct setting appears to be "parameters => 'parameters_remaining_permissions'" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10