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

[Bug 2720] Overdues which debar automatically should undebar automatically when returned
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '12

12 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2720 --- Comment #8 from Kyle M Hall <kyle(a)bywatersolutions.com> --- (In reply to comment #7) > (In reply to comment #6) > > We can have a cronjob that runs > > nightly to remove any expired debarments, and reset the borrowers.debarment > > field to 0 if the borrower no longer has any active debarments. > > If we're relying on a cron job to remove debarments, then I wonder why we > bother with the extra table? Why not run a cron job which checks for > borrowers with no overdues for whom borrowers.debarred = '9999-12-31' ? This > would exclude patrons which were restricted under a suspension in days rule. > > If we're trying to exclude patrons for whom borrowers.debarred was set > manually, maybe we need to instead create a new flag for manual restriction? I guess my idea is to have a more flexible and extensible system. Having multiple debarment fields in the borrowers table seems kludgy to me. What if a borrower is debarred for different reasons at different branches? With my proposed design, we could allow patrons to be debarred at only specific libraries if we add a branch code to the debarments table. I guess I'm just making the case that it would be better to in the long run to develop a separate table rather than keep adding more fields to the borrowers table. If plack ever becomes the primary way to run Koha, we wouldn't even need a 'quick' flag in the borrowers table, as the result could be cached. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 2720] Overdues which debar automatically should undebar automatically when returned
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '12

12 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2720 --- Comment #7 from Owen Leonard <oleonard(a)myacpl.org> --- (In reply to comment #6) > We can have a cronjob that runs > nightly to remove any expired debarments, and reset the borrowers.debarment > field to 0 if the borrower no longer has any active debarments. If we're relying on a cron job to remove debarments, then I wonder why we bother with the extra table? Why not run a cron job which checks for borrowers with no overdues for whom borrowers.debarred = '9999-12-31' ? This would exclude patrons which were restricted under a suspension in days rule. If we're trying to exclude patrons for whom borrowers.debarred was set manually, maybe we need to instead create a new flag for manual restriction? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 2720] Overdues which debar automatically should undebar automatically when returned
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '12

12 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2720 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Fines that debar |Overdues which debar |automatically, should |automatically should |undebar automatically when |undebar automatically when |paid. |returned -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 2720] Fines that debar automatically, should undebar automatically when paid.
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '12

12 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2720 --- Comment #6 from Kyle M Hall <kyle(a)bywatersolutions.com> --- (In reply to comment #5) > (In reply to comment #4) > > I would say we keep borrowers.debarred, but convert it to a boolean value. > > Convert it *back* to a boolean value! And move the date information into > borrower_debarment? Yes. It will just be a quick check to know if the borrower is currently debarred without checking the debarments table. > > We can then have that value updated each time the debarments table is > > altered. > > Which is when? Is there a line in borrower_debarment for each overdue item > which is past the limit? And the table is reviewed each time an item is > renewed or checked in?+ Each time a debarment is added to the borrower_debarments table, or a debarment is removed from the borrower_debarments table, a check will then be performed to determine if the borrower is currently debarred or not, and borrowers.debarred will be updated accordingly. > > I believe we will then need a nightly cronjob to remove expired > > debarments and update borrowers.debarred. > > I don't understand. Are we talking about a cron job or is this something > which updates each time something is checked in or renewed? Right now, Koha checks the debarment field as a date to see if it is still valid. This will no longer be effective, as we will be able to have multiple debarments with different expiration dates. We can have a cronjob that runs nightly to remove any expired debarments, and reset the borrowers.debarment field to 0 if the borrower no longer has any active debarments. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 2060] Ability to import Authorities from Staff Client
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '12

11 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2060 Jared Camins-Esakov <jcamins(a)cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #11260|0 |1 is obsolete| | --- Comment #25 from Jared Camins-Esakov <jcamins(a)cpbibliography.com> --- Created attachment 12152 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=12152&action=edit Bug 2060: Update command line MARC import scripts Expose authority import functionality to the command line import scripts, and rename them from commit_biblios_file.pl and stage_biblios_file.pl to commit_file.pl and stage_file.pl. To test (note that these instructions assume you have a MARC21 installation and are using the provided sample file): 1. Find a file of authorities (a sample file with MARC21 authorities is attached to bug 7475) and download it to your server 2. Stage the file using the following command (replace <filename> with the name of the file you saved in step 1): > misc/stage_file.pl --file <filename> --authorities 3. Note the batch number the script assigns to your batch 4. Commit the records using the following command (replace <batchnumber> with the batch number you made note of in step 3): > misc/commit_file.pl --batch-number <batchnumber> 5. Index the authorities Zebraqueue (or wait) 6. Confirm that the new authorities appear. 7. Create a matching rule with the following settings: Code: AUTHTEST Description: Personal name main entry Match threshold: 999 Record type: Authority record Search index: Heading-main Score: 1000 Tag: 100 Subfields: a Offset: 0 Length: 0 (note the ID of this matching rule) 8. Stage the authority file again, this time using the following command: > misc/stage_file.pl --file <filename> --authorities \ --match <matchingrule> 7. Revert the import with the following command: > misc/commit_file.pl --batch-number <batchnumber> --revert 8. Index the authorities Zebraqueue (or wait) 9. Confirm that the records have been removed 10. Import an authority record with the Stage MARC/Manage staged MARC tools in exactly the way you would for a bibliographic record, but choose "Authority" instead of "Bibliographic" for the record type. Signed-off-by: Elliott Davis <elliott(a)bywatersolutions.com> Testing plan delivers as it should. Signed-off-by: Jared Camins-Esakov <jcamins(a)cpbibliography.com> Rebased on latest master 11 September 2012 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 2060] Ability to import Authorities from Staff Client
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '12

11 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2060 Jared Camins-Esakov <jcamins(a)cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #11259|0 |1 is obsolete| | --- Comment #24 from Jared Camins-Esakov <jcamins(a)cpbibliography.com> --- Created attachment 12151 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=12151&action=edit Bug 7475: Teach matching rules to handle authorities * Add the code necessary to handle authorities with matching rules and import batches. * Update all the scripts that use the matcher and import batch code to use the new API. * Add authority records to the matching rules interface in the staff client. http://bugs.koha-community.org/show_bug.cgi?id=2060 Signed-off-by: Elliott Davis <elliott(a)bywatersolutions.com> Signed-off-by: Jared Camins-Esakov <jcamins(a)cpbibliography.com> Rebased on latest master 11 September 2012 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 2060] Ability to import Authorities from Staff Client
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '12

11 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2060 Jared Camins-Esakov <jcamins(a)cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #11258|0 |1 is obsolete| | --- Comment #23 from Jared Camins-Esakov <jcamins(a)cpbibliography.com> --- Created attachment 12150 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=12150&action=edit Bug 7475: Update configuration In order to make matching rules more useful for MARC21 authorities, this patch adds special indexes on previous see-from headings and LCCN. This patch does not change UNIMARC authority configuration in any way. Also modifies the Koha schema in preparation for adding authority import and matching to the Staging tools. To install: 1. Run installer/data/mysql/atomicupdate/importauthorities.pl 2. Update the following four files in your koha-dev: etc/zebradb/authorities/etc/bib1.att etc/zebradb/marc_defs/marc21/authorities/authority-koha-indexdefs.xml etc/zebradb/marc_defs/marc21/authorities/authority-zebra-indexdefs.xsl etc/zebradb/xsl/koha-indexdefs-to-zebra.xsl 3. Reindex your authorities: misc/migration_tools/rebuild_zebra.pl -a -r -v NOTE TO RM: this patch adds an atomicupdate file that needs to be incorporated into updatedatabase.pl if bug 7167 is not pushed. http://bugs.koha-community.org/show_bug.cgi?id=2060 Signed-off-by: Elliott Davis <elliott(a)bywatersolutions.com> Signed-off-by: Jared Camins-Esakov <jcamins(a)cpbibliography.com> Rebased on master 1 August 2012 Signed-off-by: Jared Camins-Esakov <jcamins(a)cpbibliography.com> Rebased on master 11 September 2012 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3462] Link see alsos in authorities
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '12

11 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3462 Jared Camins-Esakov <jcamins(a)cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #11390|0 |1 is obsolete| | --- Comment #18 from Jared Camins-Esakov <jcamins(a)cpbibliography.com> --- Created attachment 12149 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=12149&action=edit Bug 3462: Links in authorities should be hyperlinks Make see also links in both the OPAC and authority module search results into hyperlinks and not just textual strings. To test: 1. Do a search for an authority that will bring up a heading with a see also reference in the staff client and the OPAC. 2. Confirm that the see also references listed in the search results are now hyperlinks, which work. Also quiets an unnecessary warning about an uninitialized value. Signed-off-by: Jared Camins-Esakov <jcamins(a)cpbibliography.com> Rebased 26 July 2012 Signed-off-by: Jared Camins-Esakov <jcamins(a)cpbibliography.com> Rebased on master 1 August 2012 Signed-off-by: Jared Camins-Esakov <jcamins(a)cpbibliography.com> Rebased on master 6 August 2012 Signed-off-by: Jared Camins-Esakov <jcamins(a)cpbibliography.com> Rebased on master 11 September 2012 Signed-off-by: Katrin Fischer <Katrin.Fischer.83(a)web.de> Patch works nicely and is a great improvement. Tests: - Checked links for existing and non existing "see alsos" give correct search results - Verified links show up for all "see alsos" in a result list - Verified links are properly linked with the correct names - Checked logs don't show errors -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 5410] New: "Right truncation not supported" error when running link_bibs_to_authorities.pl
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '12

11 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5410 Summary: "Right truncation not supported" error when running link_bibs_to_authorities.pl Change sponsored?: --- Product: Koha Version: rel_3_0 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: fcapovilla(a)live.ca QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 This error can happen multiple times when running misc/link_bibs_to_authorities.pl with a large number of biblios : CCL parsing error (10014) Right truncation not supported ZOOM at ... I did some tests and found that the error happens when the script try to search for an authority that ends with a "?". "?" seems to be a wildcard character for truncation in CCL. Examples of CCL queries causing a "Right truncation not supported" error : Match-heading,ext="Qui, quand, quoi?" AND at='UNIF_TITLE' AND Heading-use-series-added-entry=a Match-heading,ext="Lescarbot, Marc, 1570?-1630?" AND at='PERSO_NAME' AND Heading-use-subject-added-entry=a AND Subject-heading-thesaurus=rvm A possible solution would be to find a way escape the "?"s so they aren't seen as truncations by the CCL parser. -- 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 13

[Bug 5155] New: Question marks cause problems for BiblioAddsAuthorities
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '12

11 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5155 Summary: Question marks cause problems for BiblioAddsAuthorities Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: camins(a)numismatics.org QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 When BiblioAddsAuthorities is on, personal name headings that include question marks do not automatically generate authority records, even though the exact same name without the question mark works properly. To reproduce this bug, create a new record and put, for example, "Smith, John," in 100$a and "1920-1980?" in 100$d. Save the record. There will not be any authority record linked to that heading. If you do the exact same thing but do not include the question mark, an authority record will be created. -- 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 1