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

[Bug 16881] New: Apply KohaTable and ColVis plugin on MARCdetail' s items table
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '24

02 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16881 Bug ID: 16881 Summary: Apply KohaTable and ColVis plugin on MARCdetail's items table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Allows to choose columns to display on items table in the MARCdetail page (cgi-bin/koha/catalogue/MARCdetail.pl). Also, the columns displayed are saved for each users in database. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 19590] New: doc of Clean Patron Records tool wrong about deletion scope + anonymization syspref
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19590 Bug ID: 19590 Summary: doc of Clean Patron Records tool wrong about deletion scope + anonymization syspref Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hi, I think I've found a documentation issue in the "Clean Patron Records" tool. Both the in-app + online doc [1] mention that: «patrons with outstanding fines or items checked out not saved» (the rest of the doc confirms that we are talking about removal) → wrong, see [2][3] «The anonymization will fail quietly if AnonymousPatron preference does not contain a valid value.» → wrong, according to the UI itself «The AnonymousPatron system preference is not defined. You can use this feature anyway but NULL will be used to update the checkout history.» Are these two findings correct? [1] https://koha-community.org/manual/17.05/html/03_tools.html#patrons-anonymiz… [2] excludes patrons with checked out item https://github.com/Koha-Community/Koha/blob/master/C4/Members.pm#L1040 [3] excludes patrons with unpaid fines https://github.com/Koha-Community/Koha/blob/master/tools/cleanborrowers.pl#… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 17330] New: Initiate batch item edit of items from cart (new feature? )
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17330 Bug ID: 17330 Summary: Initiate batch item edit of items from cart (new feature?) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: viktor.sarge(a)regionhalland.se QA Contact: testopia(a)bugs.koha-community.org On 16.05.03 I can initiate batch record edit from the cart, but not items edit. I realize that it's the records that are saved and not items, but /cgi-bin/koha/tools/batchMod.pl already have a checkbox for choosing which items to modify. How about showing all items for all the records chosen and you could just chose which ones to work with? I do feel that there is a possibility of people messing things up from not thinking about the difference between the saved records and the items for that record that might live in different locations. But when someone puked on a whole shelf it's a quick way to search all records on a particular shelf and marking the items as damaged. What say ye? (To be really helpful it would be good if you could check/uncheck all items based on for example location etc. of course) -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 16898] New: Show patron restriction details on OPAC user page
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16898 Bug ID: 16898 Summary: Show patron restriction details on OPAC user page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Right now if you have multiple restrictions on your account, the details of those restrictions are all string together in the message which displays in the OPAC. We should display details for each separate restriction. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 20511] New: Seasonal prediction just in the staff language
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '24

24 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20511 Bug ID: 20511 Summary: Seasonal prediction just in the staff language Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com The seasonal (season, day and monthn) prediction it doens't change according the locale defined in the patterns, the pattern uses always the language of the staff user interface. If you create a pattern with staff user language in spanish, it doesn't matter you configure the locale.. the serialq it will be in spanish. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 45

[Bug 21173] New: Run auto item modifications by age every hour and set the item age unit to hours
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '24

23 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21173 Bug ID: 21173 Summary: Run auto item modifications by age every hour and set the item age unit to hours Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Make auto item modification by age cronjob run more often than once daily. Setting this cronjob to run every hour will be set in the /etc/cron.hourly/koha-common. However 2 further changes to the automatic item modification tool to make an hourly running cronjob useful. 1. Be able to set the age of the item in hours not just days. This is so an hourly cronjob has items to alter because items will exceed the age limit more frequently than if the item age is in hours. 2. Give the user the choice of what the age starting point (time from which the age of the item is calculated) used in the cronjob is. The two possible age starting points that users have to choose between are: * Item creation (this is the age starting point in master currently) * Item last altered This is so items whic have been in the catalogue for a while can still be affected by the automatic item modification by age cronjob. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 62

[Bug 22140] New: More use of EasyAnalyticalRecords pref
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '24

19 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22140 Bug ID: 22140 Summary: More use of EasyAnalyticalRecords pref Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Like Bug 20702 defined GetHostItemsInfo does nothing if EasyAnalyticalRecords pref is disabled, there are other places where code must be dependant on this pref. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 20380] New: Email consent patron opt-in tracking for anti-spam legislation
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '24

19 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20380 Bug ID: 20380 Summary: Email consent patron opt-in tracking for anti-spam legislation Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: arm(a)hanover.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com An email consent opt-in field is something that many libraries need to accommodate, with recent legislation in US, Europe, and Canada (which may be the most strict yet). Please comment / add suggestions. Useful features would be: - Email Consent field with Authorised Values drop down allowing multiple choices to allow for different legislation e.g. Yes/No, radio button or tick box, - If Yes, then mandatory date from calendar picker - Preference to make this mandatory/non mandatory for new patron and/or at patron renewal (if mandatory it would need Yes/No rather than radio/tick box) - Preference to set mandatory/non-mandatory for OPAC self-registration (with "Yes I consent..." opt-in wording) - Ability to export data (SQL report?) based on consent choices and consent date or timestamp (for upload to mailer program) Also nice to have: - Additional separate library-set categories for Yes to receive library messages, library newsletter, new titles list, book club updates, library events etc. (each with y/n, tick box...) - Timestamp recorded when any consent field changes (to yes or from yes to no). The date picker might be enough for initial consent but legislated requirements may vary in different countries. Libraries are using 'additional attributes' as a workaround but lack the date recorded (or timestamp) for changes to the consent status, and ability to differentiate permission for core library service messages and news/marketing messages. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 21559] New: Rules for automatic framework codes
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '24

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21559 Bug ID: 21559 Summary: Rules for automatic framework codes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Allow setting rules in a system preference, what framework code should be automatically set for biblio, based on the MARC record fields. Does not affect anything if the MarcToFrameworkcodeAutoconvert system preference rules aren't used. The "Default" framework is always overridden, if the rules match, but some other framework chosen by you is always used. Explanation of the rule format: ------------------------------- The syspref is YAML, with a specific format: - <field> <value>: <frameworkcode> If the <field> in the record contains <value>, the <frameworkcode> is used for the record. <field> is one of: "xxx" (field xxx in the MARC record) "xxx/yy" (field xxx, character location yy) "xxx/yy-zz" (field xxx, character locations yy-zz) "xxx$v" (field xxx, subfield v) Fields can be combined with plus-sign, then the field values have plus-sign between them. The field-rules are checked in order from top to bottom, and the first rule with a matching value is used. If the (sub)field has been repeated in the MARC record, only the first matching (sub)field is checked. If none of the rules match, the framework code is not changed. Example: - 008/35-37 + 000/06: fin+a: BKSFIN - 000/06: a: BKS c: MU e: MP This would make record with 000/06 = "a" AND 008/35-37 = "fin" use the BKSFIN framework, and any other record with 000/06 = "a" use BKS, 000/06 = "c" would be MU, and 000/06 = "e" would give MP -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 20588] New: Elasticsearch - Apply dataTable on search fields and mapping tables
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '24

09 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20588 Bug ID: 20588 Summary: Elasticsearch - Apply dataTable on search fields and mapping tables Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com Apply dataTable on search fields and mapping tables to be able to sort and filter data. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36