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

[Bug 35172] New: Order receiving error
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '24

01 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35172 Bug ID: 35172 Summary: Order receiving error Change sponsored?: --- Product: Koha Version: 22.11 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: librarian(a)sageuniversity.in QA Contact: testopia(a)bugs.koha-community.org Created attachment 157967 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=157967&action=e… Error in order receiving I am using koha version 22.11.10.when receiving order something went wrong when loading the table 500 internal server error please see the screen shot. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '24

01 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 --- Comment #25 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Lisette Scheer from comment #24) > (In reply to Martin Renvoize from comment #23) > > > As for the --- digest thing, I feel like the logic for that one is backwards > > and strange.. we should be generating the notice all in one hit at a later > > point in time rather than queuing a notice and then munging extra stuff into > > it after the fact at various times. > > The --- digest thing also doesn't make much sense to me. > With putting it together at one point in time, would that mean that say for > hold notices when notices send every hour that before that happened it would > build and check for the patron any waiting holds that had been set to > waiting since the last one? > > Or perhaps we could set some sort of flag when the hold is trapped that gets > cleared when the notice is sent? I'd love to change the mechanic on how these notices are generated, but we should move this to a separate bug: Bug 36470 - Generate CHECKOUT, CHECKIN and HOLD digest notices should be generated at once, not amended over time When talking about the loops, I was actually thinking of the ACQORDER notice, as I had recently worked on that one :) It also has a weird way to detect repeatable sections, that does not even rely on the <order> tags, as you would think. Problem for another bug too. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '24

01 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=36470 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 24422] New: Advanced search shelving locations are restricted to the same restrictions as cataloging
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '24

01 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24422 Bug ID: 24422 Summary: Advanced search shelving locations are restricted to the same restrictions as cataloging Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Shelving locations that are setup in the LOC category allow libraries to include a location or not, based on whether they use the location in cataloging. This makes sense. What cataloger wants to sift through a bunch of shelving locations they are never going to use? However, if you allow advanced searching to use shelving locations as a limiter (AdvancedSearchTypes), if you are on the staff client in advance search, you have the same locations restricted imposed on search.pl, which is not what one would want. Staff will never be able to limit to a shelving location used at another library. I don't think that the library limitations in LOC should apply to search.pl. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4