Опция заявителя не отображается в аддоне Thunderbird в openerp

Я использую openerp 6.1.1 и пытаюсь создать кандидата из дополнения Thunderbird.

Я создал специальный модуль, чтобы добавить несколько дополнительных полей в модель hr_applicant.

Дополнение Thunderbird OpenERP не показывает возможность создания кандидата.

Когда я удаляю пользовательский модуль, я вижу эту опцию в дополнении Thunderibird.

Я не понимаю, что я делаю неправильно в пользовательском модуле:

class hr_applicant_custom (osv.osv):
  _name = 'hr.applicant'
  _inherit = 'hr.applicant'
  _columns = {
    'year_passing': fields.integer('Passing Year', help='Year of passing'),
    'experience': fields.float('Experience', digits=(3,1)),    
  }
hr_applicant_custom()

Пожалуйста посоветуй. Заранее спасибо.


person helloworld    schedule 01.07.2012    source источник


Ответы (1)


В модуле Thunderbird вы можете увидеть модель, которая наследует модель mail.thread для этого поведения. Ответственным методом является message_capable_models, который будет фильтровать модели, наследующие модель mail.thread

В вашем случае, если вы посмотрите внимательно в код модуля hr_recruitment, вы найдете hr.applicant моделью наследование mail.thread, поэтому вы увидите его в списке TB Push Mai, теперь в вашем модуле вы модифицируете атрибут _inherit модели hr.applicant, так что из-за для python MRO это будет изменение на новый класс, и теперь эта модель не подходит для создания новой записи.

Решение. попробуйте несколько моделей в _inherit, например inherit = ['mail.thread', 'hr.applicant'].

Надеюсь, это поможет.

person ifixthat    schedule 02.07.2012
comment
Это сработало. Большое спасибо. Кстати, я пробовал class hr_applicant_custom(hr_applicant), но это не сработало. Есть идеи ? Спасибо. - person helloworld; 02.07.2012
comment
@helloworld class hr_applicant_custom(hr_applicant) это не сработало, потому что, опять же, как я уже сказал, Python MRO играет большую роль, в наследовании классов, если вы дадите _inherit другое значение, тогда будет играть роль последний код, и то, что мы сделали в обоих случаях здесь, сохраняет предыдущее значение и использует новое значение, это возможная причина гибкости OpenERP Framework, иначе здесь Python MRO — это головная боль. , надеюсь, вы уловили суть - person ifixthat; 02.07.2012