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

[Bug 38716] New: Add table configuration to Hold A Specific Item table in staff interface
by bugzilla-daemon＠bugs.koha-community.org 16 Dec '24

16 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38716 Bug ID: 38716 Summary: Add table configuration to Hold A Specific Item table in staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The table showing items available for an item-specific hold in the intratnet (requestspecific on request.pl) has a hardcoded set of item fields visible. It would be helpful to add column configuration here so a library can hide those columns. We could then add more columns as optional. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 14907] Item search: Call Numbers in Item search results are ordered alphabetically
by bugzilla-daemon＠bugs.koha-community.org 16 Dec '24

16 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14907 --- Comment #21 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Katrin Fischer from comment #20) > Sorry, I am not sure I get your point. :( > > For me this patch for sorting and the generation of cn_sort are separate. > > cn_sort is generated whenever an item is edited/changed, or the touch script > is run, depending on the classification source. Of course there can be bugs > in this area too. > > For sorting we use cn_sort already in other places like inventory or the > callnumber value builder and the field should be used every where we sort on > callnumbers. > > For me the goal of this patch is to use the cn_sort data. So I'd probably > look at the itmecallnumber, cn_sort and sort by cn_sort with SQL and compare > that to what I see in item search. I would think that the goal of this report is getting the sort correct. How we do that, is another thing. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14907] Item search: Call Numbers in Item search results are ordered alphabetically
by bugzilla-daemon＠bugs.koha-community.org 16 Dec '24

16 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14907 --- Comment #20 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Sorry, I am not sure I get your point. :( For me this patch for sorting and the generation of cn_sort are separate. cn_sort is generated whenever an item is edited/changed, or the touch script is run, depending on the classification source. Of course there can be bugs in this area too. For sorting we use cn_sort already in other places like inventory or the callnumber value builder and the field should be used every where we sort on callnumbers. For me the goal of this patch is to use the cn_sort data. So I'd probably look at the itmecallnumber, cn_sort and sort by cn_sort with SQL and compare that to what I see in item search. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14907] Item search: Call Numbers in Item search results are ordered alphabetically
by bugzilla-daemon＠bugs.koha-community.org 16 Dec '24

16 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14907 --- Comment #19 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Katrin Fischer from comment #18) > (In reply to Marcel de Rooy from comment #17) > > (In reply to Katrin Fischer from comment #16) > > > But isn't this more a question of how the cn_sort is generated instead of > > > making sure it's using cn_sort for sorting? > > > > These are tightly coupled of course. > > Coupled yes, but this bug doesn't deal with the generation. This bug deals about sorting? So we should use cn_sort and make sure that cn_sort is filled correctly. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11583] Add WYSIWYG editor for HTML notices/letters
by bugzilla-daemon＠bugs.koha-community.org 16 Dec '24

16 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11583 Martin Renvoize (ashimema) <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com --- Comment #25 from Martin Renvoize (ashimema) <martin.renvoize(a)ptfs-europe.com> --- Please look at bug 35267 if your thinking about CSS options -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13945] Multiple dialogs for item that needs transferred and hold captured at checkin
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '24

15 Dec '24

1 0

[Bug 7003] Canned report to show patrons and permissions
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '24

15 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7003 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #7 from David Cook <dcook(a)prosentient.com.au> --- I've got an old local customization (written in PHP) that renders a huge table that shows patron permissions. It uses the permission tables so that it dynamically updates itself and doesn't require manual updates each time a new permission is added. (Although that means it's not translation friendly.) It's quite an unwieldy table though, because it's so long. I think Caroline has lots of good ideas there, although this isn't something I'm super keen to work on. I've thought about re-developing my existing work as a Koha plugin, but it hasn't been that popular of a report locally I think, so it's not something I've been very motivated to do either. A small part of me wants to get rid of this local customization though, so I'm a little interested in getting a simple equivalent into upstream... -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 38708] New: Add a way to list all users who have a permission
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '24

14 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38708 Bug ID: 38708 Summary: Add a way to list all users who have a permission Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com As an functional administrator I often need to list all the professional users who have a permission (any permission or a specific one). I wrote a SQL report for that but it is not convienient. We should have a way to display this information by default. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 7003] Canned report to show patrons and permissions
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '24

14 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7003 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathsabypro(a)gmail.com --- Comment #6 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- *** Bug 38708 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 8137] Checkout limit for all libraries
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '24

14 Dec '24

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

1 0