Merge lp:~therp-nl/banking-addons/ba70-fix_payment_detection into lp:banking-addons

Proposed by Stefan Rijnhart (Opener)
Status: Merged
Merged at revision: 168
Proposed branch: lp:~therp-nl/banking-addons/ba70-fix_payment_detection
Merge into: lp:banking-addons
Prerequisite: lp:~therp-nl/banking-addons/7.0-link_partner_wizard
Diff against target: 22 lines (+2/-3)
1 file modified
account_banking/banking_import_transaction.py (+2/-3)
To merge this branch: bzr merge lp:~therp-nl/banking-addons/ba70-fix_payment_detection
Reviewer Review Type Date Requested Status
Guewen Baconnier @ Camptocamp Approve
Holger Brunn (Therp) Approve
Review via email: mp+162358@code.launchpad.net

Description of the change

As payment functionality has been split off to account_banking_payment now, account_banking only interacts with the payment model very minimally. There was already a check to see if account_payment was installed but it assumed that account_banking_payment is then also installed as this is now an autoinstalled glue module depending on the two other modules. Of course, it can easily be the case that this module is not in the addons path so that we need to check if this module itself is actually installed. This branch fixes this by checking for a column that account_banking_payment adds to the model.

To post a comment you must log in.
Revision history for this message
Holger Brunn (Therp) (hbrunn) wrote :

I think
try:
  from openerp.addons import $module_name
except:
...

is a cleaner (and more pythonic) approach to detect the availability of a module

And are lines 18f an artifact of your prerequisite-frenzy or do they have anything to do with the issue at hand?

review: Needs Fixing
Revision history for this message
Guewen Baconnier @ Camptocamp (gbaconnier-c2c) wrote :

> I think
> try:
> from openerp.addons import $module_name
> except:
> ...
>
> is a cleaner (and more pythonic) approach to detect the availability of a
> module

A module could be importable from python (as soon as it lives in the addons path), but not actually installed on the current database.

Revision history for this message
Stefan Rijnhart (Opener) (stefan-opener) wrote :

Import seems unsafe as per Guewens comment, as it covers the current situation in which the module may be available but is set to uninstallable pending the migration of the code.

l.18/19 are redundant as payment_lines is already assigned an empty value a couple of lines earlier (not shown in the diff). Consider it an unrelated refactoring.

Revision history for this message
Holger Brunn (Therp) (hbrunn) wrote :

Thanks for the clarifications!

review: Approve
Revision history for this message
Guewen Baconnier @ Camptocamp (gbaconnier-c2c) :
review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'account_banking/banking_import_transaction.py'
2--- account_banking/banking_import_transaction.py 2013-05-03 13:56:25 +0000
3+++ account_banking/banking_import_transaction.py 2013-05-03 13:56:26 +0000
4@@ -820,7 +820,8 @@
5 journal_obj = self.pool.get('account.journal')
6 move_line_obj = self.pool.get('account.move.line')
7 payment_line_obj = self.pool.get('payment.line')
8- has_payment = bool(payment_line_obj)
9+ has_payment = bool(
10+ payment_line_obj and 'date_done' in payment_line_obj._columns)
11 statement_line_obj = self.pool.get('account.bank.statement.line')
12 statement_obj = self.pool.get('account.bank.statement')
13 imported_statement_ids = []
14@@ -856,8 +857,6 @@
15 ('date_done', '=', False)], context=context)
16 payment_lines = payment_line_obj.browse(
17 cr, uid, payment_line_ids)
18- else:
19- payment_lines = False
20
21 # Start the loop over the transactions requested to match
22 transactions = self.browse(cr, uid, ids, context)

Subscribers

People subscribed via source and target branches

to status/vote changes: