| Summary: | Should getletter not use the fallback to default? | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Marcel de Rooy <m.de.rooy> |
| Component: | Notices | Assignee: | Martin Renvoize (ashimema) <martin.renvoize> |
| Status: | CLOSED INVALID | QA Contact: | Testopia <testopia> |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | jonathan.druart, nick, tomascohen |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26734 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28487 |
||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
We should not fall back to en, but to whatever is the "Default" tab in that installation. I thought that was the case tbh :( (In reply to Katrin Fischer from comment #1) > We should not fall back to en, but to whatever is the "Default" tab in that > installation. I thought that was the case tbh :( Well look at the code carefully. It depends on a few conditions: 1) Do you use TranslateNotices pref 2) Did the patron fill in the language for notices? If you do and patron lang is e.g. 'en' but there is no notice for en, there is no fallback in the above. As long as most people not have filled the language, it does not hurt too much.. So I think you are right, but it should fallback to default :) It's handled in GetPreparredLetter
638 $letter = getletter( $module, $letter_code, $branchcode, $mtt, $lang );
639
640 unless ( $letter ) {
641 $letter = getletter( $module, $letter_code, $branchcode, $mtt, 'default' )
642 or warn( "No $module $letter_code letter transported by " . $mtt ),
643 return;
644 }
(In reply to Jonathan Druart from comment #4) > It's handled in GetPreparredLetter > > 638 $letter = getletter( $module, $letter_code, $branchcode, $mtt, > $lang ); > 639 > 640 unless ( $letter ) { > 641 $letter = getletter( $module, $letter_code, $branchcode, > $mtt, 'default' ) > 642 or warn( "No $module $letter_code letter transported by > " . $mtt ), > 643 return; > 644 } Ah. Thats good. Didnt test it on master ;) Thx. Will have to check if there are other callers to getletter that dont do the same thing? And if this change in GetPreparedLetter came together in older versions.. getletter is the "raw" subroutine to get what you asked in parameter (for tools/letter.pl) It's correctly handled in GetPreparedLetter since the beginning, see commit c49bdc3a8d8e5a9389a27a8dca90544ff5c42f95 Bug 17762: Add the lang parameter to C4::Letters::getletter Looks like those occurrences need to be double-checked:
members/printfeercpt.pl:my $letter = C4::Letters::getletter( 'circulation', 'ACCOUNT_CREDIT', C4::Context::mybranch, 'print', $patron->lang );
members/printinvoice.pl:my $letter = C4::Letters::getletter( 'circulation', 'ACCOUNT_DEBIT', C4::Context::mybranch, 'print', $patron->lang );
misc/cronjobs/overdue_notices.pl: my $letter = C4::Letters::getletter( 'circulation', $overdue_rules->{"letter$i"}, $branchcode, undef, $patron->lang );
misc/cronjobs/overdue_notices.pl: my $letter_exists = C4::Letters::getletter( 'circulation', $overdue_rules->{"letter$i"}, $branchcode, $effective_mtt, $patron->lang ) ? 1 : 0;
pos/printreceipt.pl: C4::Letters::getletter( 'pos', 'RECEIPT', C4::Context::mybranch, 'print' );
I caught most of these occurrences in bug 26734.. looks like overdue slips need the same handling. It re-opens a question I raised in the roadmap sheet though: https://annuel.framapad.org/p/koha_21.05_roadmap Namely, "Should we converge back to /printslip.pl + circ/print-slip.tt or continue down the route of a controller + template for each slip type?" This is invalid, getletter should not have a fallback. *** Bug 26787 has been marked as a duplicate of this bug. *** |
Looking at the code: sub getletter { my ( $module, $code, $branchcode, $message_transport_type, $lang) = @_; .. $lang = 'default' unless( $lang && C4::Context->preference('TranslateNotices') ); .. my $sth = $dbh->prepare(q{ SELECT * FROM letter WHERE module=? AND code=? AND (branchcode = ? OR branchcode = '') AND message_transport_type LIKE ? AND lang =? ORDER BY branchcode DESC LIMIT 1 }); $sth->execute( $module, $code, $branchcode, $message_transport_type, $lang ); my $line = $sth->fetchrow_hashref or return; .. I am just wondering if I miss something. If the language is passed (which is often just a $patron->lang or so), then we are fetching with that language! If that notice has not been translated yet, we will not fallback to en ?!