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

[Bug 17892] New: Move _extract_biblionumbers to a module
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17892 Bug ID: 17892 Summary: Move _extract_biblionumbers to a module Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org See bug 17273 -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 17848] New: Count not updated in digest-only notices
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17848 Bug ID: 17848 Summary: Count not updated in digest-only notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: rbit(a)rbit.cz QA Contact: testopia(a)bugs.koha-community.org When using <count>> in CHECKIN/CHECKOUT/RENEWAL notices, its value is not correctly updated. A letter is prepared during the first round and then its updated with iterated data items as they come. This means that placeholders like <<count>> are not updated anymore so we can see letters saying eg. "you returned 3 items", but in the fact there is much more of them listed in: ---- <<biblio.title>> ---- -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 17730] New: Uniform mapping for biblio.biblionumber (Unimarc)
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17730 Bug ID: 17730 Summary: Uniform mapping for biblio.biblionumber (Unimarc) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: gmcharlt(a)gmail.com Reporter: dubyk(a)library.lviv.ua QA Contact: testopia(a)bugs.koha-community.org Created attachment 57999 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=57999&action=ed… Screenshot I try to deal with empty links to record details in the search. I found that this occurs when used mapping 090$9<>biblio.biblionumber (in uk-UA Unimarc tables) and typical use UNIMARCslim2intranetResults.xsl. In Koha mapping of biblio.biblionumber and MARC-fields mentioned in many files: etc / zebradb / marc_defs / unimarc / biblios / record.abs 25 melm 001 Local-number,Local-number:n 26 # Local-number (biblionumber can be either in 090$9 or, on some setup, on 001) 28 melm 090$9 Local-number,Local-number:n etc / zebradb / marc_defs / unimarc / biblios / biblio-koha-indexdefs.xml 9 <index_control_field tag="001"> 10 <target_index>Local-number:n</target_index> 11 </index_control_field> 20 <index_subfields tag="090" subfields="9"> 21 <target_index>Local-number:w</target_index> 22 <target_index>Local-number:n</target_index> 23 </index_subfields> etc / zebradb / marc_defs / unimarc / biblios / biblio-zebra-indexdefs.xsl 47 <xslo:template match="marc:controlfield[@tag='001']"> 48 <z:index name="Local-number:w"> 49 <xslo:value-of select="."/> 50 </z:index> 51 <z:index name="Local-number:n"> 52 <xslo:value-of select="."/> 53 </z:index> 54 </xslo:template> 63 <xslo:template mode="index_subfields" match="marc:datafield[@tag='090']"> 64 <xslo:for-each select="marc:subfield"> 65 <xslo:if test="contains('9', @code)"> 66 <z:index name="Local-number:w Local-number:n"> 67 <xslo:value-of select="."/> 68 </z:index> 69 </xslo:if> 70 </xslo:for-each> 71 </xslo:template> koha-tmpl / opac-tmpl / bootstrap / en / xslt / UNIMARCslim2OPACDetail.xsl 21 <xsl:variable name="biblionumber" select="marc:datafield[@tag=090]/marc:subfield[@code='a']"/> koha-tmpl / intranet-tmpl / prog / en / xslt / UNIMARCslim2intranetDetail.xsl 22 <xsl:variable name="biblionumber" select="marc:datafield[@tag=090]/marc:subfield[@code='a']"/> koha-tmpl / opac-tmpl / bootstrap / en / xslt / UNIMARCslim2OPACResults.xsl 25 <xsl:variable name="biblionumber" 26 select="marc:datafield[@tag=090]/marc:subfield[@code='a']"/> koha-tmpl / intranet-tmpl / prog / en / xslt / UNIMARCslim2intranetResults.xsl 25 <xsl:variable name="biblionumber" select="marc:controlfield[@tag=001]"/> t / db_dependent / Biblio.t 84 'biblio.biblionumber' => { tagfield => '999', tagsubfield => 'c' }, biblio.biblionumber in UNIMARC-tables: ru-RU 090^9 es-ES 001^@ en 001^@ fr-FR 001^@ pl-PL 999^9 it-IT 001^@ uk-UA 090^9 That is, in the context of biblio.biblionumber mentioned next subfields: 090^9 001^@ 999^9 090^a 999^c Probably for greater uniformity is better to use one subfield for biblio.biblionumber. Maybe 001^@? -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 17718] New: Allow usage of Smartform API (Czech only)
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17718 Bug ID: 17718 Summary: Allow usage of Smartform API (Czech only) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: rbit(a)rbit.cz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Enable to use Smartform API to simplify petron registration process namely address entering. This service allows address autocompletion for any address in the Czech Republic including street names and numbers. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 17706] New: MARC staging fails with "Upload status: Denied" when memcached is enabled
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17706 Bug ID: 17706 Summary: MARC staging fails with "Upload status: Denied" when memcached is enabled Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: mirko(a)abunchofthings.net QA Contact: testopia(a)bugs.koha-community.org In 16.11.00 with memcached enabled, staging MARC records fails with "Upload status: Denied". It works after disabling memcached. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 17694] New: Add human friendly REST documentation
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17694 Bug ID: 17694 Summary: Add human friendly REST documentation Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: benjamin.rokseth(a)kul.oslo.kommune.no, brendan(a)bywatersolutions.com, jonathan.druart(a)bugs.koha-community.org, koha-bugs(a)lists.koha-community.org, lari.taskula(a)jns.fi, testopia(a)bugs.koha-community.org, tomascohen(a)gmail.com Depends on: 16212, 17432 With Bug #17432 we allowed the output of a computer friendly json representation of the swagger specification. We should now add a human friendly 'pretty' form too. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16212 [Bug 16212] Swagger specification separation and minification https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17432 [Bug 17432] Remove requirement to minify swagger.json -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 17581] New: Have possibility to edit due date to avoid to do a renewal
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17581 Bug ID: 17581 Summary: Have possibility to edit due date to avoid to do a renewal Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: marjorie.barry-vila(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi, It would be fine to have possibility to edit due date for a loan in progress to avoid to do a renewal. Only for staff. Regards, Marjorie -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 17514] New: Record details page uses incorrect class "results_summary "
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17514 Bug ID: 17514 Summary: Record details page uses incorrect class "results_summary" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The record details page re-uses the class results_summary which is semantically incorrect and causes unwanted interactions with the styling of the actual results page which also uses the results_summary class. We should change the instances of the results_summary class to details_summary on this page. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 17474] New: Make possible to create fee after hold is filled and checked out to patron
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17474 Bug ID: 17474 Summary: Make possible to create fee after hold is filled and checked out to patron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 17463] New: Wrong recipient for suggestion' s notice in branch specific
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17463 Bug ID: 17463 Summary: Wrong recipient for suggestion's notice in branch specific Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: marjorie.barry-vila(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org Hi, There is test plan to understand the problem: Branch A with borrower A and librarian A, Branch B with librarian B Notice ACCEPTED, ORDERED, AVAILABLE set to each branch - borrower A done a suggestion A - librarian from branch A accepted suggestion A - email for suggestion ACCEPTED sent to borrower A - librarian from branch A ordered suggestion A, a biblio is created (biblio A) - email for suggestion ORDERED sent to borrower A - librarian from branch B ordered an other copy from the same biblio A (not from suggestion A, really from biblio A) - Order from librarian B is also related to suggestion A : this is the problem. - librarian B received his item before librarian A - email for suggestion AVAILABLE sent to borrower A while item for branch A is not arrived yet. Do you understand me? Order from an other branch for the same biblio should not be related to the initial suggestion. Regards, Marjorie -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2