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

[Bug 36305] New: Inventory tools need adjustments for CSRF
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '24

25 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36305 Bug ID: 36305 Summary: Inventory tools need adjustments for CSRF Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The main forms don't use 'op' other than checking for the existence Problem follow-ups use an ajax post -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 14250] Don't allow to generate discharges for patrons with fines
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '24

25 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14250 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|additional_work_needed | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37018] SQL injection using q under api/
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '24

25 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37018 --- Comment #161 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #160) > Work as expected. > > Do you have another concern about it? Yes, the validation allows invalid operators at a deeper level as mentioned in earlier comment. Here is proof: Run this script use Modern::Perl; use Data::Dumper qw/Dumper/; use Koha::REST::Plugin::Query; my $query = { priority => [ { '=', 2 }, { '>', 5 } ] }; print Dumper( Koha::REST::Plugin::Query::_validate_query( $query ) ); $query = { priority => [ { '||', 2 }, { ';;', 5 } ] }; print Dumper( Koha::REST::Plugin::Query::_validate_query( $query ) ); $query = { "item_id" => { "<", "5" } }; print Dumper( Koha::REST::Plugin::Query::_validate_query( $query ) ); $query = { "item_id" => { "||", "5" } }; print Dumper( Koha::REST::Plugin::Query::_validate_query( $query ) ); As you can see, the second query is invalid with || operator and the fourth query is invalid too. What are the results: $VAR1 = ''; $VAR1 = ''; $VAR1 = ''; [Invalid operator found in query] This shows that the second query is approved, and only the fourth is rejected (where the operator is a level higher in the recursion). That is actually wrong. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14007] Values listed in OpacHiddenItems should not appear in OPAC facets
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '24

25 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14007 --- Comment #35 from David Cook <dcook(a)prosentient.com.au> --- You're a legend, David (Nind). One day we'll solve the OpacHiddenItems problem that causes the search result number mismatch problem... one day... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14007] Values listed in OpacHiddenItems should not appear in OPAC facets
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '24

25 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14007 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |This fixes item type facets release notes| |in OPAC search results when | |using OpacHiddenItems. | |Facet values in | |OpacHiddenItems are now | |filtered out and no longer | |displayed. | | | |For example, to | |hide Map item types (item | |type code = MP) in the | |OPAC: | |- add "itype: ['MP']" | |to OpacHiddenItems | |- | |previously, map items would | |not be displayed in the | |search results, but the | |'Item type' facet under | |'Refine your search' would | |still display the 'Maps' | |value | |- now, the item type | |facet no longer displays | |the 'Maps' value --- Comment #34 from David Nind <david(a)davidnind.com> --- Testing notes (using KTD): 1. Test with both Elasticsearch 7 and Zebra. I couldn't start KTD with ES8, only ES7. 2. Top: start up KTD with Elastic search 7. Once tested with Elasticsearch, change SearchEngine to Zebra and reindex. 3. Note: The number of search results does not match. For example, I edited "Programming perl" (biblionumber = 262) to change the Koha item type to Maps, and edited the item so that it was Maps as well. Searching for 'perl' returns 10 actual results, which doesn't match with "Your search returned 11 results". -- 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 25 Oct '24

25 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11583 --- Comment #18 from David Cook <dcook(a)prosentient.com.au> --- Hmm... take a look at the premium TinyMCE plugin called "Merge Tags". That sounds interesting... I just tried out its CodePen... and I couldn't get <<Client.Name>> to work but << Client.Name >> looks pretty good in the TinyMCE visual editor. That said, in the source code editor it looks like << Client.Name >> And [%Client.Name => 'stuff' %] gets turned into [%Client.Name => 'stuff' %] Maybe it does something fancy at load/save time, but I doubt it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

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

25 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11583 --- Comment #17 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Sally Lodico from comment #15) > I rarely bother with TinyMCE. I find it to be more trouble than it's worth, > but the newer template designers, like https://grapesjs.com/, would make > creating responsive and email ready notices a dream. I'd much rather have a > tool like this than a WYSIWYG. TinyMCE does drive me crazy... I hadn't heard of GrapesJS but it looks interesting. It's actually like you read my mind. I was wondering what FOSS options there were for block content editing like this... -- Unfortunately, at a glance, it would have the same problem as TinyMCE. If you type in <<borrowers.firstname>> into a text block it will turn it into <<borrowers.firstname>> It's not just the <<>> syntax; it's also the Template Toolkit syntax. There's times we do things like [% stuff = { 'this' => 'that' } %] which could be turned into [% stuff = { 'this' => 'that'} %] But maybe GrapesJS is more customizable than TinyMCE. But I think it would be very challenging or impossible with GrapesJS too. -- We were probably overambitious using Template Toolkit in Notices after all. Many email templates could be done using a simple token replacement system, but AUTO_RENEWALS heavily requires Template Toolkit logic. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 14007] Values listed in OpacHiddenItems should not appear in OPAC facets
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '24

25 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14007 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #173243|0 |1 is obsolete| | --- Comment #33 from David Nind <david(a)davidnind.com> --- Created attachment 173309 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=173309&action=e… Bug 14007: Filter search result values to remove OpacHiddenItems values This change filters the values from the OpacHiddenItems syspref out of their corresponding search results facets. Note: This does not mean that all values from hidden items are filtered out of facets. Rather, it just means that facet data that matches OpacHiddenItems is filtered out. This is an imperfect fix, but it is a practical fix that has been requested by more than one library. Test plan: 0. Apply the patch and koha-plack --restart kohadev 1. Go to http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=29 2. Add an item with an item type of "Maps" 3. Go to http://localhost:8081/cgi-bin/koha/admin/preferences.pl?op=search&searchfie… 4. Fill in OpacHiddenItems with the following: itype: ['MP'] 5. Go to http://localhost:8080/cgi-bin/koha/opac-search.pl?idx=&q=test&weight_search… 6. Note that "Maps" does not appear in the "Item types" facet 7. Go to http://localhost:8081/cgi-bin/koha/catalogue/search.pl?q=test 8. Note that "Maps" does appear in the "Item types" facet 9. ***Repeat this test plan using both Elasticsearch and Zebra indexing*** 10. prove -v t/Koha/SearchEngine/Search.t Signed-off-by: David Nind <david(a)davidnind.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14007] Values listed in OpacHiddenItems should not appear in OPAC facets
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '24

25 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14007 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38086] New: UpdateItemLocationOnCheckin could be the return date
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '24

25 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38086 Bug ID: 38086 Summary: UpdateItemLocationOnCheckin could be the return date Change sponsored?: --- Product: Koha Version: Main 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 When an items is returned, a library may have the UpdateItemLocationOnCheckin system preference set to CART. This is generic, and could be more useful. Some libraries might like the option of putting something like "Returned 4/10/2024" in place of CART. So, in UpdateItemLocationOnCheckin, instead of entering _ALL_: CART instead, we could enter something like _ALL_: RETURNDATE -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2