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

[Bug 13888] 'Lists' permission should allow/disallow using the lists module in staff
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '24

23 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13888 --- Comment #4 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Andrew Auld from comment #3) > I would like to bump this, as turning off lists permissions for a staff user > doesn't seem to stop the lists button from appearing on the home page, or > stop the user from accessing and managing lists. > > Has this bug been forgotten about? I think it's just not "annoying enough" unfortunately. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 918] impossible to delete a field in unimarc authorities framework
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '24

22 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=918 Phil Ringnalda <phil(a)chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |37163 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37163 [Bug 37163] Fix the redirect after deleting a tag from an authority framework to load the right page -- 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 21 Jun '24

21 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14907 Laura Escamilla <Laura.escamilla(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Laura.escamilla@bywatersolu | |tions.com --- Comment #7 from Laura Escamilla <Laura.escamilla(a)bywatersolutions.com> --- +1 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 25836] New: MARC fields not able to be reordered in basic editor
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '24

21 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25836 Bug ID: 25836 Summary: MARC fields not able to be reordered in basic editor Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl >From bug 7882, it seems that MARC fields should be able to be reordered, however it does not appear to be working. For instance, if I have a record with 3 650 fields and 2 651 fields, I cannot move the 651 fields above the 650 fields. I can rearrange the 650 fields amongst themselves, but that's it. The move icon/hamburger shows on all fields, which leads one to think that all fields can be reordered, when this is clearly not the case. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 14210] Manage staged MARC records deletes replaced item when undoing import into catalog
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '24

21 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14210 Laura Escamilla <Laura.escamilla(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Laura.escamilla@bywatersolu | |tions.com --- Comment #10 from Laura Escamilla <Laura.escamilla(a)bywatersolutions.com> --- +1 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37156] New: Internal routine _GetCircControlBranch is used outside of C4::Circulation
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '24

21 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37156 Bug ID: 37156 Summary: Internal routine _GetCircControlBranch is used outside of C4::Circulation Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org git grep _GetCircControlBranch Koha/Item.pm Koha/Recall.pm reserve/request.pl svc/letters/preview see bug 5801 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 35402] Update the OPAC and staff interface to Bootstrap 5
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '24

21 Jun '24

1 0

[Bug 37145] New: Koha ERM data provider name search broken
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '24

21 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37145 Bug ID: 37145 Summary: Koha ERM data provider name search broken Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: kyle(a)bywatersolutions.com CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com This is broken because the FQDN for the service has changed and we do not handle the 301 gracefully. To test: 1) Browser to ERM / eUsage / Data roviders 2) Click "New data provider" 3) Start typing anything into "Data provider name" 4) Note the error: "Something went wrong: Error: Internal Server Error." -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 34478] Full CSRF protection
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '24

21 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34478 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |37150 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37150 [Bug 37150] Can't delete single title from a list using the "Remove from list" link -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 27421] New: Porting tools/stage-marc-import.pl to BackgroundJob
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '24

21 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27421 Bug ID: 27421 Summary: Porting tools/stage-marc-import.pl to BackgroundJob Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: domm(a)plix.at QA Contact: testopia(a)bugs.koha-community.org Hi! I recently started to convert tools/stage-marc-import.pl to use the new BackgroundJobs, because we're using the Plack version, which does not like the old forking implementation. While I've realized now that we can still use the old CGI script by running it directly via the frontend Apache, I'm not very happy with this workaround. So, here is my current first sort-of-working prototype: https://github.com/Koha-Community/Koha/compare/master...domm:MARCImporter Before I continue my work, I'd really appreciate some feedback if what I'm doing makes sense and matches your general plans. Obviously there is still a lot missing: * Proper feedback after starting the staging process (i.e. a link to the job) * Probably I will also need to check if the job has finished, and present a link to the next step (copy the staged records into the library) (which AFAIK will also need to be converted to BackgroundJobs) I also have a few questions: * Is it neccessary to get the job-size before starting it? If yes, then I assume I'll have to first parse the MARC file to get the job size, throwing the results away (and this might not work, because we want to do the parsing in the background in the first place). Or is there an easy way to get the number of records? * When I try to update job_size later, I get an exception (something like "job_size not tested") * Can I actually use BatchStageMarcRecords in BackgroundJob? * I see I can pass a batch size to BatchStageMarcRecords. But this will not result in more forking? This is "only" used to fire the progress callback? I'm also not sure if the bug tracker or the dev mailing list is the best place to discuss my questions? Anyway, looking forward to some feedback! Greetings, domm -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 136