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

[Bug 14367] History for MARC records. Roll back changes on a timeline or per field.
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '21

02 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14367 --- Comment #61 from Donna <bwsdonna(a)gmail.com> --- *** Bug 28500 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14367] History for MARC records. Roll back changes on a timeline or per field.
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '21

02 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14367 Donna <bwsdonna(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bwsdonna(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 26561] New: Number on claims tab not showing when translated
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '21

02 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26561 Bug ID: 26561 Summary: Number on claims tab not showing when translated Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr, kyle(a)bywatersolutions.com In German we only see: / Claim(s) (or Rückgebebehauptungen...) when there should be 0 / 0 be displaying in the patron account in staff. I believe we have had similar problems in the past with 0 values? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 28505] New: Hold fulfillment policy should not prevent selection of libraries when holds are being placed
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '21

02 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28505 Bug ID: 28505 Summary: Hold fulfillment policy should not prevent selection of libraries when holds are being placed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In bug 15532 the idea of 'hold pickup library match' / hold_fulfillment_policy was that in system where items float or rotate a patron would be able to place a hold for delivery anywhere, but it would only fill when the item arrived at a branch that met the policy. Recent work on validating the pickup location when placing the hold seems to have broken the ability to place a hold for delivery that violates rules now, but may be valid in the future. When placing holds the pickup locations should not be limited by the hold fulfillment policy -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 5800] Hold Policy "home library only" incompatible with CircControl "patron home library"
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '21

02 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5800 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=28503 -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 15261] Verify if checkout or hold request periods overlap with existing holds
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '21

02 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15261 --- Comment #96 from Arthur Suzuki <arthur.suzuki(a)biblibre.com> --- Just had a quick check at this patch. Seems the controls on the overlapping reserves is done in the interface code (opac/place-reserve.pl and so on) and not in C4/Reserves. This is then not checked for ILS-DI and RestAPI. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11083] Authority Search Result Display should be XSLT Driven
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '21

02 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11083 Julian Maurice <julian.maurice(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|gmcharlt(a)gmail.com |julian.maurice(a)biblibre.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11083] Authority Search Result Display should be XSLT Driven
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '21

02 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11083 Julian Maurice <julian.maurice(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |julian.maurice(a)biblibre.com Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11083] Authority Search Result Display should be XSLT Driven
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '21

02 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11083 --- Comment #2 from Julian Maurice <julian.maurice(a)biblibre.com> --- Created attachment 121537 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121537&action=e… Bug 11083: Add ability to generate authority summary using XSLT This patch only affects authority search results in the staff interface. It adds a new system preference AuthorityXSLTResultsDisplay. If set, each authority search result MARCXML will be transformed using the XSLT at the given filename or URL. The output will be displayed in place of the default summary. If errors occur, the XSLT is ignored and the default summary is displayed. The syspref value can contain {langcode} and {authtypecode} which will be replaced by the appropriate value (resp. current language and authority type code) Test plan: 1. Apply patch and run updatedatabase 2. Verify that authority search results are not affected yet. 3. Create an XSLT file (for instance in /home/koha/xslt/en/GEOGR_NAME.xsl) 4. Set AuthorityXSLTResultsDisplay syspref value to /home/koha/xslt/{langcode}/{authtypecode}.xsl 5. Do an authority search that returns GEOGR_NAME results. Verify that the summary matches what you expect from your XSLT 6. Do an authority search that returns authorities of other types. Verify that the default summary is displayed. Example of a minimal XSLT: <?xml version='1.0' encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:marc="http://www.loc.gov/MARC21/slim" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output omit-xml-declaration="yes"/> <xsl:template match="marc:record"> <xsl:element name="div"> <xsl:attribute name="class"> <xsl:text>authority-summary</xsl:text> </xsl:attribute> <xsl:value-of select="marc:datafield[@tag='151']/marc:subfield[@code='a']"/> </xsl:element> </xsl:template> </xsl:stylesheet> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 20662] New: The "most poplular" function on the opac does not honour opac supression
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '21

02 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20662 Bug ID: 20662 Summary: The "most poplular" function on the opac does not honour opac supression Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org The "most popular" function on the OPAC does not honour the opac suppression in the 942$n subfield. I think this is because "most popular" is based on a database query, and the opac suppression is in a MARC field which is indexed in Zebra. I think the solution is probably to create a biblio.suppressed field and have the 942$n store data in that field. Then we check that database field for things like "most popular" and other database queries. -- You are receiving this mail because: You are watching all bug changes.

1 6