https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42503 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off --- Comment #46 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- (In reply to Lucas Gass (lukeg) from comment #45)
A couple questions, not necessarily blockers:
1. In CreatePicklistFromItemMap, do we need to fetch the itype_description, ccode_description, and location_description each time through the loop?
`get_description_by_koha_field` already uses Koha::Cache::Memory::Lite, so repeated calls for the same value are cached. No change needed.
2. Should these fallback to code, or undef, in the cases of no description? my $ccode_description = Koha::AuthorisedValues->get_description_by_koha_field( { kohafield => 'items.ccode', authorised_value => $item->ccode } )->{lib};
It already returns undef when no description found (the hashref is {}, so ->{lib} is undef). That's appropriate - the column is nullable.
3. What is $context in this ... context? sub api_query_fixer { my ( $self, $query, $context, $no_quotes ) = @_; return Koha::Biblios->new->api_query_fixer( $query, 'biblio', $no_quotes ); }
The $context parameter is the nesting prefix that tells the query fixer where to find the fields it needs to rewrite. Example: In /api/v1/acquisitions/orders, biblio is embedded one level deep. When a user sorts by "biblio.isbn", DBIC cannot resolve it directly because isbn lives on the biblioitems table, not biblio. The fixer is called with $context = 'biblio': Input: "biblio.isbn" Output: "biblio.biblioitem.isbn" This lets DBIC resolve the correct join path. If $context were empty (as in /api/v1/biblios), it would match bare field names: Input: "isbn" Output: "biblioitem.isbn" In our holds queue endpoint, biblio is embedded directly on the queue item, so we pass $context = 'biblio' when delegating to Koha::Biblios->api_query_fixer. The outer call from the controller uses $context = '' because the holds queue item itself is at the top level. I will try to document this better.
Blocker:
1. Setting HidePatronName to 'Don't show', the patron name still appears in the holds queue!
Right. I added an exception for superlibrarians, I'll just remove it to preserve behavior for now.
2. Schema changes to Result/TmpHoldsqueue.pm should be move to their own patch.
Oops! Bad commits reorganization! -- You are receiving this mail because: You are watching all bug changes.