[Koha-bugs] [Bug 17964] TT syntax for notices - Prove that CHECKIN and CHECKOUT are compatible

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17964

--- Comment #15 from Jonathan Druart <jonathan.druart at bugs.koha-community.org> ---
(In reply to Marcel de Rooy from comment #13)
> In the interface I used this checkin notice:
> 
> The following items have been checked in:
> ----
> [% biblio.title %]  [% old_issues.returndate %]
> [% old_issues.issue_id %]
> ----
> Thank you.
> 
> And it does not show me the old issues information. No date and no id.

I will take a look.

> If I look at sub _get_tt_params, I am having doubts if the correct old
> issues record would be found when just using itemnumber as a foreign key.
> Note that I repeatedly checked in and out the same item. Looking at the
> code, I would expect the wrong old issue record found. Should you not look
> at the last one instead of the first one? The "historical" code uses: ORDER
> BY timestamp DESC in _parseletter_sth..

Same.

> Another question: How do you use plural in _get_tt_params ? If we are not
> using it, why add it?

You should take a look at the whole enhancement, tree of dependencies.
If you take a look bug 17981, which is almost the top of the tree, you will see
all the deps. There is a remote branch to see all patches applied. I think it's
important to have this overview in mind before QAing separately the different
bug reports.
It is hard to make a such big tree and trying to reflect what you are trying to
do on all the different steps.

(In reply to Marcel de Rooy from comment #14)
> And as a side note: Is this code in get_tt_params really correct:
>             else {    # $ref eq 'ARRAY'
>                 my $object;
>                 if ( @{ $tables->{$table} } == 1 ) {    # Param is a single
> key
>                     $object = $module->search( { $pk => $tables->{$table} }
> )->next();
>                 }
>                 else {                                  # Params are
> mutliple foreign keys
>                     croak "Multiple foreign keys (table $table) should be
> passed using an hashref";
>                 }
> I was thinking that I could pass a few primary keys in an array (see
> historical code). But this code croaks on "multiple fk's". Plus a typo :)

That could be implement later, I just implemented what I used. During the whole
process I did not need it. Maybe later?

-- 
You are receiving this mail because:
You are watching all bug changes.