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 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #103167|0 |1 is obsolete| | --- Comment #90 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Created attachment 104568 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=104568&action=e… Bug 8132: Adding a new message 'last_item_for_hold' blocking item deletion If an item is the last one of a biblio that have biblio-level hold placed on it, we should block the deletion. It takes effect if the hold is found (W or T), to follow existing behavior for item-level holds. If we want to block deletion for any holds we should deal with it on a separate bug report. Test plan: 0/ Setup Apply the patches Create Biblio B1 with 1 item Create Biblio B2 with 2 items Create Biblio B3 with 1+ item Create Biblio B4 with 1+ item Create Biblio B5 with 1+ item Place a biblio-level hold on B1 and B2 Place an item-level hold on B3 and B4 Confirm the item-level hold for the items of B3 to mark it waiting. 1/ Delete those 6 items in a batch => delete of item from B1 is blocked on first screen - only 1 item left and there is a biblio-level hold on the record => delete of items from B2 is *not* blocked on first screen - One of them will block the deletion, but so far we are not aware of that situation => delete of item from B3 is blocked on first screen - there is a waiting item-level hold placed on the item => delete of item from B4 is *not* blocked - there is a hold but it is not found => delete of item from B5 is *not* - there is no reason to block its deletion Note that you can only select items from B2, B4 and B5 2/ Select them and confirm the deletion => Nothing happened and you get a message saying that one of the 2 items from B2 is blocking the whole deletion process 3/ Remove the biblio-level hold from B2 4/ Repeat 1 => The deletion has been effective! => Note that there is something a bit weird as we are blocking items from a biblio that has biblio-level holds on it (not found), but we do not blocking the deletion of an item with a waiting item-level hold Signed-off-by: Kelly McElligott <kelly(a)bywatersolutions.com> Signed-off-by: Victor Grousset/tuxayo <victor(a)tuxayo.net> Signed-off-by: Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> -- 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 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #103166|0 |1 is obsolete| | --- Comment #89 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Created attachment 104567 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=104567&action=e… Bug 8132: No changes but disable checkboxes When the list of items is displayed we already know if there will be a problem during the deletion. So let's disable the checkbox to tell the user in advance that items cannot be deleted. Signed-off-by: Kelly McElligott <kelly(a)bywatersolutions.com> Signed-off-by: Victor Grousset/tuxayo <victor(a)tuxayo.net> Signed-off-by: Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> -- 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 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25373] New: Bug 23290 Security fix break all XSLT entities
by bugzilla-daemon＠bugs.koha-community.org 08 May '20

08 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25373 Bug ID: 25373 Summary: Bug 23290 Security fix break all XSLT entities Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org By default display XSL have : <!DOCTYPE stylesheet [<!ENTITY nbsp " " >]> Since Bug 23290   are replaced with nothing, mangling xsl style sheet output. Worse if nbsp is inside a xslt:text tag some (all?) xml parsers return an error with an empty output. Error: xsltParseTemplateContent: xslt:text content problem compilation error: file /home/koha/webdatas/public/XSLT/OPACResults.xsl element text xsltParseTemplateContent: xslt:text content problem at /home/koha/src/Koha/XSLT_Handler.pm line 343. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[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