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

[Bug 8132] Batch delete tool deletes items with holds on them
by bugzilla-daemon＠bugs.koha-community.org 08 May '20

08 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8132 --- Comment #88 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- (In reply to Marcel de Rooy from comment #87) Again, the only things this change does is: * Add feedback on the interface about items that cannot be deleted (existing behaviour with the 4 error codes: book_on_loan, not_same_branch, book_reserved, linked_analytics). Note that "book_reserved" means that an item with item-level hold on it that is W or T cannot be deleted (*existing behaviour*) * Prevent phantom holds that are created when the last item of a bibliographic record that with a [biblio-level] hold on it is deleted. In that case we forbid the deletion. Nothing else. It is the implementation of the need described several times in this bug report and this has been waited for a long time now. I should not that, in master, you are not allowed to "delete all items" for the bibliographic record: "1 hold(s) on this record. You must delete all holds before deleting all items." Individual deletion is allowed however. If I misunderstood the need or if the implementation does not answer it, then feel free to obsolete the patches and provide another approach. But I think it is what we want here. If this is considered an improvement to the existing behaviour, but not perfect, then it should be pushed and improved later (your "And even to discuss" part is far behind what we are doing here). It would be good to get opinions from other contributors as it seems we are stuck :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8132] Batch delete tool deletes items with holds on them
by bugzilla-daemon＠bugs.koha-community.org 08 May '20

08 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8132 --- Comment #87 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- The second patch here actually says that it is not 'safe to delete' the only remaining item where the biblio has a biblio level hold. I do not agree with that statement. The item can perfectly be deleted. The biblio level hold may be filled by a future item and can be removed too. This might be a preferential thing. The critical or major aspect of this bug imo is that the batch delete tool still deletes an item with an ITEM level hold. Note btw that the remark about phantom holds in comment1 is not valid in this case (or at least any more). The item delete cascades to reserves. And a biblio delete cascades to reserves too. So we have no phantom holds. Might depend on the definition of 'phantom'.. And even to discuss: What if we said that an item delete should convert an item level hold to biblio level instead of deleting the hold ? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25420] New: sayang
by bugzilla-daemon＠bugs.koha-community.org 08 May '20

08 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25420 Bug ID: 25420 Summary: sayang Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: jalilihsan115(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 104544 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=104544&action=e… Hacked By Mr.24434 Hacked By Mr.24434 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 10517] koha-restore fails to create mysqluser@mysql_hostname so zebra update fails
by bugzilla-daemon＠bugs.koha-community.org 08 May '20

08 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10517 --- Comment #29 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Rudolf Byker from comment #25) > OK, if you really need to support older versions, let's do it cleanly. By the way, Martin Renvoize is the release manager and Katrin Fischer is the QA manager, so ultimately they're the ones who decide what gets pushed. I'm just a fellow contributor. Don't feel like you need to listen to me. They're the ones to listen to. You may also find contributing easier if you're using git-bz (https://wiki.koha-community.org/wiki/Git_bz_configuration) or even the community's Docker testing images which comes bundled with git-bz (https://gitlab.com/koha-community/koha-testing-docker) I notice you submitted a patch last year as well. Good to see you back here! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10517] koha-restore fails to create mysqluser@mysql_hostname so zebra update fails
by bugzilla-daemon＠bugs.koha-community.org 08 May '20

08 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10517 --- Comment #28 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Rudolf Byker from comment #25) > OK, if you really need to support older versions, let's do it cleanly. Here > is a way to check if the user exists: > > EXISTS=$(mysql -uroot -p -s -e "select count(*) from mysql.user where user = > 'asdf'" | tail -n 1) > if [[ $EXISTS -gt 0 ]] > then > echo "Now delete the user." > fi Sounds like a plan to me, although I think it would be better to create a new function in koha-functions.sh, since we need to drop the user in koha-restore as well as koha-remove. I think we batch too many SQL statements together for these CLI utilities. But, I'm not planning on doing that work anytime soon. So don't feel obligated to listen to that. Ultimately what I was trying to say before was that koha-remove already uses the DROP USER IF EXISTS syntax, so it seems fair to use it in koha-restore too, even if it causes problems for people using older DB versions, since that problem already exists in the master codebase. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10517] koha-restore fails to create mysqluser@mysql_hostname so zebra update fails
by bugzilla-daemon＠bugs.koha-community.org 08 May '20

08 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10517 --- Comment #27 from Victor Grousset/tuxayo <victor(a)tuxayo.net> --- (In reply to Rudolf Byker from comment #21) > Probably your dev environment. I've never had this issue, and I'm using my > own patch. Did you check which process is still using the user using `ps -u > kohadev-koha`? starman and apache -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10517] koha-restore fails to create mysqluser@mysql_hostname so zebra update fails
by bugzilla-daemon＠bugs.koha-community.org 07 May '20

07 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10517 --- Comment #26 from Victor Grousset/tuxayo <victor(a)tuxayo.net> --- (In reply to Katrin Fischer from comment #23) > in bugzilla it will then appear > automatically in a comment, if you use git bz. @Rudolf that's the cause I think. Your commit seems fine but if you don't use git-bz[1] you have to manually copy the commit message in the comment created when uploading an attachment. [1] https://wiki.koha-community.org/wiki/Git_bz_configuration -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14369] Only show 'Create labels' link on staged records import when status is 'Imported'
by bugzilla-daemon＠bugs.koha-community.org 07 May '20

07 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14369 Joy Nelson <joy(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|20.05.00 |20.05.00, 19.11.06 released in| | CC| |joy(a)bywatersolutions.com Status|Pushed to master |Pushed to stable --- Comment #11 from Joy Nelson <joy(a)bywatersolutions.com> --- Backported to 19.11.x for 19.11.06 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13557] Add hint for on-site checkouts to list of current checkouts in OPAC
by bugzilla-daemon＠bugs.koha-community.org 07 May '20

07 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13557 Joy Nelson <joy(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to master |Pushed to stable CC| |joy(a)bywatersolutions.com Version(s)|20.05.00 |20.05.00, 19.11.06 released in| | --- Comment #6 from Joy Nelson <joy(a)bywatersolutions.com> --- Backported to 19.11.x for 19.11.06 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10561] DisplayOPACiconsXSLT and DisplayIconsXSLT descriptions should be clearer
by bugzilla-daemon＠bugs.koha-community.org 07 May '20

07 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10561 Joy Nelson <joy(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joy(a)bywatersolutions.com Status|Pushed to master |Pushed to stable Version(s)|20.05.00 |20.05.00, 19.11.06 released in| | --- Comment #16 from Joy Nelson <joy(a)bywatersolutions.com> --- Backported to 19.11.x for 19.11.06 -- You are receiving this mail because: You are watching all bug changes.

1 0