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

[Bug 27689] New: Kiki
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '23

23 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27689 Bug ID: 27689 Summary: Kiki Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: bugs.koha-community.org Assignee: koha-bugs(a)lists.koha-community.org Reporter: jancokasusemongko(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 27693] New: Add ability to sort ElasticSearch configuration tables
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '23

23 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27693 Bug ID: 27693 Summary: Add ability to sort ElasticSearch configuration 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: severine.queune(a)bulac.fr Being able to sort the tables in search engine configuration could be very useful. That way it would be easier to check different settings, like which field are a "String" or "Date" type (search fields tab), which field are facetted, we can sort by Marc field to check the index used (biblio tab), etc. A personnal reflexion : I never understood why these tables have a drag and drop option ? Is there a secret use never found out ? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 27705] New: Unfold facet groups
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '23

23 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27705 Bug ID: 27705 Summary: Unfold facet groups Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org A great option could be to have an option to unfold the group facet "ITEMTYPECAT". If I use the example given in the manual : it's great to filter on "Movies" items, but I don't have a Blu-ray player, I would be happy to unfold the "Movies" category to only select the "DVD" item type ! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 27722] New: Eliminate 'All' as an option from display location in OPAC and Koha news
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '23

23 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27722 Bug ID: 27722 Summary: Eliminate 'All' as an option from display location in OPAC and Koha news 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When the Koha News tool was just for OPAC News and 'librarian interface' all was a good option. Now that we have 10+ content areas options 'All' is just confusing. It should be eliminated as an option. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 27721] New: Circulation Workflow (Statuses)
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '23

23 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27721 Bug ID: 27721 Summary: Circulation Workflow (Statuses) Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be great if there were some kind of centralized workflow for processing items that would allow libraries to handle items the way they need to at each branch. Right now we have rules, and then we have statuses. There are some workflows for statuses peppered throughout the preferences, but nothing centralized, and far too limiting. I think some of these settings could be centralized through a common workflow interface, similar to (or maybe combined with) UpdateItemLocationOnCheckin, and be given some better flexibility. Please understand that I am just throwing this out there for a discussion. Some of these ideas might be redundant and might even be too complex a change for Koha. But, for the sake of discussion and brainstorming, what if we could define common triggers and actions, and allow libraries to combine these with common elements? Basically, it would be great to have a framework in which we could define what elements would trigger what kind of actions, and in what order. Here is where I am coming from. We have a library that would like to create a status for lost items that are in collections. Easy enough. We would like to make sure that when the item status is changed from long overdue to lost and in collections that the fee is not removed. We would also like it if an item with this status were checked in at some or all libraries, it would pause the check in with a message stating that it is in collections, are you sure you want to check this item in? Maybe we just simply need more status preferences? But, it seems we have a few peppered through the settings as it is, and it would be great if we had these in a central framework where we could see them all and prioritize them and have more options as to how they work. Does this status charge? Does it refund? Should it be confirmed? Should it block? Should it reroute? Should it notify a staff member? Should it go to a staff member for processing? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 31954] New: Patron search has no h1 heading
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '23

20 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31954 Bug ID: 31954 Summary: Patron search has no h1 heading Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org For accessibility every page should have an h1 level heading and have a clear hierarchical structure of headings. Patron search only has 2 h3 headings. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 23979] New: "Account is locked" message on moremember.pl should be displayed on the "Check out" tab in addition to the "Details" tab
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '23

20 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23979 Bug ID: 23979 Summary: "Account is locked" message on moremember.pl should be displayed on the "Check out" tab in addition to the "Details" tab Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: george(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 21311 removes the "This account has been locked!" message from the OPAC when a patron account has been locked because someone has attempted to log into that account with an incorrect password more than the number of times specified by the system preference FailedLoginAttempts. This means that a patron may not know that their account has been locked if someone other than themselves has attempted to hack their account. Bug 21312 adds an "Account is locked" message on the patron's "Details" tab when a patron has locked their account by logging in with an incorrect password more than the number of times specified by the system preference FailedLoginAttempts. Most public library staff access a patron's account through the "Check out" tool which takes them directly to the "Check out" tab on the patron's account rather than the "Details" tab. The "Check out" tool is, after all, the default action of the header_search input box on the Koha home page. Having the "Account is locked" message only on the "Details" tab means that when a patron comes into the library and says "I don't understand why I can't get into my account" when staff look up the patron's account through "Check out", as they normally do, they have to take the extra step of switching to the "Details" tab to find out that the "Account is locked." The "Account is locked" message on moremember.pl should be displayed on the "Check out" tab in addition to the "Details" tab. George -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 22854] New: Add separate column for administrative locked patron
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '23

20 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22854 Bug ID: 22854 Summary: Add separate column for administrative locked patron Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- See bug 21336. This is now arranged by using the same column login_attempts. login_attempts > pref_value means locked login_attempts < 0 means admin lock Do we need one or even two new columns? [1] locked: regular lock (resulting from entering wrong password), boolean replacing the check attempts > pref. Note that changing the pref might lock or unlock users now. Do we want that? [2] admin_locked: administrative lock, resulting from e.g. removing GDPR consent, boolean -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 22785] New: Manage Multiple Matches when importing through Stage Marc Record Import
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '23

19 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22785 Bug ID: 22785 Summary: Manage Multiple Matches when importing through Stage Marc Record Import 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: joy(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Work to be done: On the stage-marc-import.pl screen, the wording would change from: [X] records with at least one match in catalog per matching rule "Y" To [X] records with one match in catalog per matching rule "Y" [X] records with two or more matches in catalog per matching rule "Y" On the manage-marc-import.pl?import_batch_id=#### screen, each record number that is a match would be displayed (multiple matches). The user would then be able to click to see all matches (modal/popup) and select (checkbox) which record(s) they would like to overlay. User would have the option of selecting none, one, or multiple records. - if there are items on the imported record and items are being imported then only one record could be selected - selecting multiple records would overlay the record onto each selected record - no records existing in the catalog would be merged by this tool - the default selection would be the first record found -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 123

[Bug 21924] New: Make default subfields order to correspond with MARC21 habit
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '23

19 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21924 Bug ID: 21924 Summary: Make default subfields order to correspond with MARC21 habit Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In the MARC21 specifications, there is habit to write first subfields with alphabetical codes and then subfields with numerical code. Koha do it in other way by default and we need to change the order manually very often. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2