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

[Bug 28197] New: checkmarc.pl gives false positive for UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28197 Bug ID: 28197 Summary: checkmarc.pl gives false positive for UNIMARC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com checkmarc.pl L54 # checks biblio.biblionumber and biblioitem.biblioitemnumber (same tag and tab=-1) work in MARC21 as they are in 999 But in UNIMARC base data they are different tag biblio.biblionumber 001 @ biblioitems.biblioitemnumber 090 a No idea if sample data is correct but Tamil's UNIMARC Koha demo have this so it's should be good. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 28161] New: Allow Koha::Patron->extended_attributes be passed a library_id
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28161 Bug ID: 28161 Summary: Allow Koha::Patron->extended_attributes be passed a library_id Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Koha::Patron::Attributes->filter_by_branch_limitations accepts the parameter, and falls back to C4::Context->userenv->{branch} if omitted. Lacking the parameter in Koha::Patron->extended_attributes makes it always fallback to userenv, thus forcing the caller to deal with that instead of just passing the parameter. Examples: - A CLI script with a --library_id param for setting extended attributes would be forced to mock a userenv for checks to work - An API route would need to deal with that as well. A minor and harmless change adding this parameter would allow more straight-forward use of this method. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 28145] New: Patron Attribute Class field allows for free text OR if PA_CLASS defined no blank value available
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28145 Bug ID: 28145 Summary: Patron Attribute Class field allows for free text OR if PA_CLASS defined no blank value available Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: erica.rohlfs(a)equinoxOLI.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In versions 20.05 and 20.11 If a PA_CLASS authorized value has not been defined, when the user creates a new patron attribute type, the "Class" field is now a free text box. In previous versions, this field would be a blank dropdown. If the user writes in a "Class" when creating an attribute, Koha is recognizing the grouping on the patron account. However, writing in a Class on the patron attribute type screen does not automatically create an authorized value for the PA_CLASS. If an authorized value for PA_CLASS has been defined, then that is the only option for a user to select when creating a patron attribute type. In previous versions, the user would still have the ability to select the "blank" option from the Class dropdown (if that attribute is not being categorized into a class). Now, if a PA_CLASS value exists, the user must put the attribute into a Class. To Recreate: 1. Make sure no PA_CLASS values are previously defined 2. Administration › Patron attribute types > New Patron Attribute Type 3. Scroll down to the last field, "Class" 4. Observe that the Class box allows for free text 5. Save your patron attribute 6. Administration › Authorized values > select PA_CLASS 7. Observe that the free text class you created is not an authorized value 8. Now create an authorized value for PA_CLASS 9. Go back to Administration › Patron attribute types > New Patron Attribute Type 10. Scroll down to the last field, "Class" and observe that the PA_CLASS value you just created is your only option in the dropdown (no blank option) - which groups your patron attribute type into a class -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 28120] New: Koha Account pay is logging fine amountoutstanding as 0 when paying selected lines
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28120 Bug ID: 28120 Summary: Koha Account pay is logging fine amountoutstanding as 0 when paying selected lines Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We have hardcoded a 0 into the logs in Koha/Account.pm 170 new_amountoutstanding => 0, To recreate: 1 - Find a patron with debits, or charge a debit manually 2 - On the patron's accoutning tab Select 'Make a payment' 3 - Select the line and click 'Pay selected' 4 - Pay less than the full amount owed 5 - Go to Tools->log viewer 6 - Enter the patrons borrowernumber into 'Object' and hit enter 7 - Notice the fines log says 'new_amountoutstanding' => 0 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 28117] New: Provide a way to strip special characters for placeholders in OPACOPACSearchForTitleIn
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28117 Bug ID: 28117 Summary: Provide a way to strip special characters for placeholders in OPACOPACSearchForTitleIn Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: eugenegf(a)yahoo.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 119342 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=119342&action=e… OPACSearchForTitleIn In OPACSearchForTitleIn, we give a way for OPAC users to search for similar materials in other libraries. Placeholders available are: {BIBLIONUMBER}, {CONTROLNUMBER}, {TITLE}, {ISBN}, {ISSN} and {AUTHOR}. If for example the author is a conference name, this would mean this placeholder will have extra characters like open and close parenthesis: "(" ")" and semi-colons. If this search query will be passed to InternetArchive Scholar, it will have a query parser error because the query format is like below: author:('query search') So if the author is "Jose Rizal National Centennial Commission (1961: Manila)", the corresponding search query will be: author:('Jose Rizal National Centennial Commission "(1961:" Manila)') So I propose for a new system preference that will let you add special characters to ignore for placeholders. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 28115] New: Reference items do not honor OPACResultsLibrary
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28115 Bug ID: 28115 Summary: Reference items do not honor OPACResultsLibrary 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: -Set up reference as an AV -Set up an item to have a different holdingbranch than it's homebranch -Go to the OPAC and look at the Availability line -It shows the homebranch -Try changing the OPACResultsLibrary system pref -No matter what you set OPACResultsLibrary to it will display the homebranch This should honor the system preference -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 28076] New: SIP should optionally ignore external auth when logging in the server account
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28076 Bug ID: 28076 Summary: SIP should optionally ignore external auth when logging in the server account Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When setting up a SIP user in Koha, they aere often a local user and don't exist in external identity managers - i.e. for sites using SSO via LDAP / CAS / SHIB the SIP user does not exist in the external DB It would be nice to have a switch to avoid checking SIP user against LDAP etc. This would be useful in the case where LDAP is down but self checks could remain operational. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 28109] New: Add a 'koha only' authentication path
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28109 Bug ID: 28109 Summary: Add a 'koha only' authentication path Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org For koha services like SIP or connexion the users are often created local to the instance and don't exist in external identity providers. It would be nice to have a way to specify that some logins should only check against Koha to avoid LDAP delays etc. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 28104] New: last line of sitemapindex.xml lacks EOL
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28104 Bug ID: 28104 Summary: last line of sitemapindex.xml lacks EOL Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: bargioni(a)pusc.it QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)bugs.koha-community.org, robin(a)catalyst.net.nz CC: jonathan.druart(a)bugs.koha-community.org $ /usr/sbin/koha-sitemap --generate instance generates file /var/lib/koha/instance/sitemap/sitemapindex.xml without the EOL of the last line. XML parsers can complain, e.g.: $ xmllint --format /var/lib/koha/instance/sitemap/sitemapindex.xml /var/lib/koha/instance/sitemap/sitemapindex.xml:22: parser error : expected '>' </sitemapindex> ^ /var/lib/koha/instance/sitemap/sitemapindex.xml:22: parser error : Premature end of data in tag sitemapindex line 3 </sitemapindex> ^ --- Comment #1 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- I don't recreate the problem. Can you provide more detail please? $ perl debian/scripts/koha-sitemap --enable kohadev Sitemap enabled for kohadev $ perl debian/scripts/koha-sitemap --generate kohadev Sitemap directory for kohadev doesn't exist. Creating. $ xmllint --format /var/lib/koha/kohadev/sitemap/sitemapindex.xml <?xml version="1.0" encoding="UTF-8"?> <sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <sitemap> <loc>http://kohadev.myDNSname.org:8080/sitemap0001.xml</loc> <lastmod>2021-04-09</lastmod> </sitemap> </sitemapindex> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 28098] New: Allow for editing public parameter for Upload tool
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28098 Bug ID: 28098 Summary: Allow for editing public parameter for Upload tool Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: eugenegf(a)yahoo.com QA Contact: testopia(a)bugs.koha-community.org Currently (19.11), the Upload (Any File) tool does not let you change the parameter for Public. There should be a way for editing uploaded files into public and vice versa. Currently, if you want to do this, you have to hack the database and change the 'public' column to 1 if it's public and remove the value '1' if you don't want to make it public. --- Comment #1 from Séverine Queune <severine.queune(a)bulac.fr> --- *** Bug 28099 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4