https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #2 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 194108 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=194108&action=edit Bug 41950: Make +count embeds sortable via SQL COUNT subqueries Currently, +count embeds (e.g. claims+count) are computed in Perl via $object->$relation->count during to_api serialization. This means they cannot be used in _order_by and each count triggers a separate SQL query per row (N+1). This patch makes dbic_merge_prefetch detect +count embeds and, when a matching DBIC relationship exists, inject a correlated COUNT subquery via +select/+as instead of adding a prefetch. The order_by entries referencing count aliases are fixed up to strip the me. prefix, since +as aliases are virtual columns not bound to a table. In to_api, the is_count handler now checks for the pre-computed column via get_column before falling back to the Perl-level ->count call. This preserves backward compatibility for Koha-level methods that don't have a corresponding DBIC relationship. To test: 1. Run: $ prove t/Koha/REST/Plugin/Query.t => SUCCESS 2. Run: $ prove t/db_dependent/Koha/Object.t => SUCCESS 3. Run: $ prove t/db_dependent/Koha/REST/Plugin/Objects.t => SUCCESS 4. Run: $ prove -r t/db_dependent/api/v1 => SUCCESS Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #194107|0 |1 is obsolete| | --- Comment #3 from David Nind <david@davidnind.com> --- Created attachment 194191 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=194191&action=edit Bug 41950: Unit tests for sortable +count embeds Add tests to verify that +count embeds produce +select/+as attributes instead of a prefetch, enabling SQL-level sorting by count columns. Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #194192|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #6 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 194339 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=194339&action=edit Bug 41950: Make +count embeds sortable via SQL COUNT subqueries Currently, +count embeds (e.g. claims+count) are computed in Perl via $object->$relation->count during to_api serialization. This means they cannot be used in _order_by and each count triggers a separate SQL query per row (N+1). This patch makes dbic_merge_prefetch detect +count embeds and, when a matching DBIC relationship exists, inject a correlated COUNT subquery via +select/+as instead of adding a prefetch. The order_by entries referencing count aliases are fixed up to strip the me. prefix, since +as aliases are virtual columns not bound to a table. In to_api, the is_count handler now checks for the pre-computed column via get_column before falling back to the Perl-level ->count call. This preserves backward compatibility for Koha-level methods that don't have a corresponding DBIC relationship. To test: 1. Run: $ prove t/Koha/REST/Plugin/Query.t => SUCCESS 2. Run: $ prove t/db_dependent/Koha/Object.t => SUCCESS 3. Run: $ prove t/db_dependent/Koha/REST/Plugin/Objects.t => SUCCESS 4. Run: $ prove -r t/db_dependent/api/v1 => SUCCESS Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@openfifth.c | |o.uk -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #194339|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #9 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 194342 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=194342&action=edit Bug 41950: Make +count embeds sortable via SQL COUNT subqueries Currently, +count embeds (e.g. claims+count) are computed in Perl via $object->$relation->count during to_api serialization. This means they cannot be used in _order_by and each count triggers a separate SQL query per row (N+1). This patch makes dbic_merge_prefetch detect +count embeds and, when a matching DBIC relationship exists, inject a correlated COUNT subquery via +select/+as instead of adding a prefetch. The order_by entries referencing count aliases are fixed up to strip the me. prefix, since +as aliases are virtual columns not bound to a table. In to_api, the is_count handler now checks for the pre-computed column via get_column before falling back to the Perl-level ->count call. This preserves backward compatibility for Koha-level methods that don't have a corresponding DBIC relationship. To test: 1. Run: $ prove t/Koha/REST/Plugin/Query.t => SUCCESS 2. Run: $ prove t/db_dependent/Koha/Object.t => SUCCESS 3. Run: $ prove t/db_dependent/Koha/REST/Plugin/Objects.t => SUCCESS 4. Run: $ prove -r t/db_dependent/api/v1 => SUCCESS Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #194341|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #11 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 198671 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198671&action=edit Bug 41950: Unit tests for sortable +count embeds Add tests to verify that +count embeds produce +select/+as attributes instead of a prefetch, enabling SQL-level sorting by count columns. Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.

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

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #198672|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #14 from David Nind <david@davidnind.com> --- Created attachment 198676 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198676&action=edit Bug 41950: Make +count embeds sortable via SQL COUNT subqueries Currently, +count embeds (e.g. claims+count) are computed in Perl via $object->$relation->count during to_api serialization. This means they cannot be used in _order_by and each count triggers a separate SQL query per row (N+1). This patch makes dbic_merge_prefetch detect +count embeds and, when a matching DBIC relationship exists, inject a correlated COUNT subquery via +select/+as instead of adding a prefetch. The order_by entries referencing count aliases are fixed up to strip the me. prefix, since +as aliases are virtual columns not bound to a table. In to_api, the is_count handler now checks for the pre-computed column via get_column before falling back to the Perl-level ->count call. This preserves backward compatibility for Koha-level methods that don't have a corresponding DBIC relationship. Test plan: 1. Apply patches 2. Run: $ ktd --shell k$ prove t/Koha/REST/Plugin/Query.t \ t/db_dependent/Koha/Object.t \ t/db_dependent/Koha/REST/Plugin/Objects.t => SUCCESS: Tests pass! 3. Sign off :-D Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #16 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- (In reply to Jonathan Druart from comment #15)

1. This needs to be documented somewhere

Agreed.

2. It was not clear to me why we couldn't sort by checkout count, so I've added

@ Koha/Schema/Result/Borrower.pm:2271 @ __PACKAGE__->has_many( +__PACKAGE__->has_many( + "checkouts", + "Koha::Schema::Result::Issue", + { "foreign.borrowernumber" => "self.borrowernumber" }, + { cascade_copy => 0, cascade_delete => 0 }, +);

And it's now possible: curl -u koha:koha --request GET 'http://dev-intra.localhost/api/v1/patrons?_order_by=+me.checkouts_count' --header "x-koha-embed: checkouts+count" --header "Content-Type: application/json"|jq

However the test is now failing. Wouldn't it better to add the relationship directly in dbic as it's certainly one of the biggest need for this feature?

Especially because you advertise it in comment 0.

The whole point was to make something generic, that pairs with the existing pattern. if we were to add _count relationships everywhere then we would need do a lot of scaffolding for adding a `+count` embed which we just want to avoid i.e. if you have a relationship, you can now embed the count automagically, and this patch makes it sortable? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Signed Off --- Comment #18 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- (In reply to Jonathan Druart from comment #17)

I think we must make it sortable when +count can be embedded, otherwise how the consumer can know when it's sortable or not?

I'm going to provide a follow-up for the trivial cases we didn't do the right thing with relationships (including Koha::Patron->checkouts which is 8yro and we didn't have this infrastructure yet). I don't think this should be a blocker for this enhancement. The current situation is consumers don't know which fields they can sort on, and get a meaningful 400 error when they can't. That's the contract with the API. This dev is making many of those succeed instead of returning the already established 400. We can think of some annotation, some work on the API markdown to alert about this. I'm open to ideas, but pushing this as-is puts us in a better place, overall. Marking SO as it was, while we discuss how to make it even better. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #20 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Current status: Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #198676|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #22 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 198981 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198981&action=edit Bug 41950: Make +count embeds sortable via SQL COUNT subqueries Currently, +count embeds (e.g. claims+count) are computed in Perl via $object->$relation->count during to_api serialization. This means they cannot be used in _order_by and each count triggers a separate SQL query per row (N+1). This patch makes dbic_merge_prefetch detect +count embeds and, when a matching DBIC relationship exists, inject a correlated COUNT subquery via +select/+as instead of adding a prefetch. The order_by entries referencing count aliases are fixed up to strip the me. prefix, since +as aliases are virtual columns not bound to a table. In to_api, the is_count handler now checks for the pre-computed column via get_column before falling back to the Perl-level ->count call. This preserves backward compatibility for Koha-level methods that don't have a corresponding DBIC relationship. Test plan: 1. Apply patches 2. Run: $ ktd --shell k$ prove t/Koha/REST/Plugin/Query.t \ t/db_dependent/Koha/Object.t \ t/db_dependent/Koha/REST/Plugin/Objects.t => SUCCESS: Tests pass! 3. Sign off :-D Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #24 from Jonathan Druart <jonathan.druart@gmail.com> --- I have found those remaining ones: biblio.uncancelled_orders+count current_item_level_holds+count biblio.uncancelled_orders+count current_item_level_holds+count bundle_items_lost+count bundle_items_not_lost+count With this solution we won't be able to sort by them. Isn't it a problem? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #26 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- (In reply to Tomás Cohen Arazi (tcohen) from comment #25)

(In reply to Jonathan Druart from comment #24)

...

I have found those remaining ones: biblio.uncancelled_orders+count current_item_level_holds+count biblio.uncancelled_orders+count current_item_level_holds+count bundle_items_lost+count bundle_items_not_lost+count

With this solution we won't be able to sort by them. Isn't it a problem?

Making an `<attribute>+count` sortable is an enhancement per se. If they are not, a 400 is returned. I insist it is out of the scope of this bug to deal with all the edge cases. This bug is not introducing things that cannot be sorted, but making most of them sortable :-D

Just to clarify: I believe if someone finds a non-sortable one, they should file a bug, dependent on this one. And anyone in the community can work/solve them if they want/need. Picking `biblio.uncancelled_orders+count` as an example, solving that implies moving the filtering down to the DBIC level as I did (as an example) with the Koha::Patron->overdues. Unless the implementation I proposed is fundamentally wrong (i.e. this should be done in a totally different way) I don't think this is a blocker. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #27 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 199031 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199031&action=edit Bug 41950: (follow-up) Add DBIC relationship aliases for +count embeds Adds DBIC relationship aliases so that +count embeds advertised in the API specs are backed by actual database relationships, making them sortable via the SQL COUNT subquery infrastructure. New aliases: - Borrower: checkouts (issues) - Aqbookseller: baskets (aqbaskets), invoices (aqinvoices) - Ticket: updates (ticket_updates) - ErmEholdingsPackage: resources (erm_eholdings_resources) - Biblio: holds (reserves) Koha methods are updated to use the new relationship names directly, following the one-liner style: Koha::Foo->_new_from_dbic( scalar ... ) Note: checkouts on Borrower and subscriptions on Aqbookseller already had matching DBIC relationships. comments on Illrequest, requests on IllBatch, and items on Biblio also already existed. Test plan: 1. Apply patch 2. Run: $ ktd --shell k$ prove t/Koha/REST/Plugin/Query.t \ t/db_dependent/api/v1/patrons.t \ t/db_dependent/api/v1/acquisitions_vendors.t \ t/db_dependent/Koha/REST/Plugin/Objects.t \ t/db_dependent/Koha/Biblio.t => SUCCESS: All tests pass 3. Verify sorting works: GET /api/v1/patrons x-koha-embed: checkouts+count _order_by: -me.checkouts_count => SUCCESS: Patrons sorted by checkout count 4. Sign off :-D Assisted-by: Sonnet 4.6 (Anthropic) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42592 --- Comment #29 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- It makes sense to me to move this bug forward as it addresses many of the places where the UI doesn't currently provide sorting and doesn't remove sorting anywhere. We should not hold up this improvement while waiting for more complex work to address the outliers (for which Tomas has already filed separate bugs). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42592 [Bug 42592] Flag +count embeds that cannot be sorted -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #31 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- (In reply to Jonathan Druart from comment #30)

My concern is to know how we will prevent new +count occurrences that won't have the corresponding dbic relation (i.e. how do we write an xt test for that, what I tried but failed).

Yeah, I'm trying too and don't like the results. It's always a bit fragile.

And how do we document that, how the consumers can know if they can sort on it or not?

On QA I always enforce the relationship name. There are some old ones and some I didn't QA myself. I've just added two coding guidelines: * https://wiki.koha-community.org/wiki/Coding_Guidelines#.5BDRAFT.5D_PERL15.1.... * https://wiki.koha-community.org/wiki/Coding_Guidelines#.5BDRAFT.5D_PERL15.1.... Those rules I'm pushing to the handbook as well. PS: I wanted them voted but the meeting was over when I was done. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #33 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- (In reply to Tomás Cohen Arazi (tcohen) from comment #32)

(In reply to Jonathan Druart from comment #30)

...

And how do we document that, how the consumers can know if they can sort on it or not?

I filed bug 42592 to discuss possible implementations for this. My plan is to annotate un-sortable `+count` embeds on the spec, and have `redocly` render that nicely on the API docs page. If that is too hard, then we can just put a clear notice in the endpoint description markdown.

This is done. And I also patched `koha-api-docs` to correctly display this. I'll work on the aesthetics of the API docs at some point but the main issue is addressed now! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #198980|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199031|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #35 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Created attachment 199294 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199294&action=edit Bug 41950: Make +count embeds sortable via SQL COUNT subqueries Currently, +count embeds (e.g. claims+count) are computed in Perl via $object->$relation->count during to_api serialization. This means they cannot be used in _order_by and each count triggers a separate SQL query per row (N+1). This patch makes dbic_merge_prefetch detect +count embeds and, when a matching DBIC relationship exists, inject a correlated COUNT subquery via +select/+as instead of adding a prefetch. The order_by entries referencing count aliases are fixed up to strip the me. prefix, since +as aliases are virtual columns not bound to a table. In to_api, the is_count handler now checks for the pre-computed column via get_column before falling back to the Perl-level ->count call. This preserves backward compatibility for Koha-level methods that don't have a corresponding DBIC relationship. Test plan: 1. Apply patches 2. Run: $ ktd --shell k$ prove t/Koha/REST/Plugin/Query.t \ t/db_dependent/Koha/Object.t \ t/db_dependent/Koha/REST/Plugin/Objects.t => SUCCESS: Tests pass! 3. Sign off :-D Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #37 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Created attachment 199296 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199296&action=edit Bug 41950: (QA follow-up): Add more tests The tests were lacking a 'real' scenario proving the sorting on a _counts works at the DB level prove t/Koha/REST/Plugin/Query.t Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #38 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- (In reply to Pedro Amorim (ammopt) from comment #37)

Created attachment 199296 [details] [review] Bug 41950: (QA follow-up): Add more tests

Thank you for the constructive feedback and proactively making this development better with your thoughts and follow-up! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #39 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Thanks everyone! Pushed to main for 26.11! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 --- Comment #40 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- This apparently broke receiving orders - see bug 42995. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |43042 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43042 [Bug 43042] 500 error when receiving an order in acquisitions -- You are receiving this mail because: You are watching all bug changes.