openerp-community-reviewer team mailing list archive

[Pedro Manuel Baeza <pedro.baeza@xxxxxxxxx>]

Public bug reported:

As seen on bug #1294887, some menus doesn't appear translated because
their definitions on XML have an ID with reference to the base module,
so that translation export tool include them on base translation file,
not on each module. In this serie of consequences, only loading base
module loads these translations, but on the base loading, translations
are not loaded because the elements don't exist. The only way to handle
this is to install module (for example purchase), and then update base
module again.

An easy solution to this is to rename these IDs to another ones, and
it's very interesting that this lands on trunk before the v8 debuts,
because this change is not easy to be done on an stable branch.

This is the complete list of menus with this problem that I have
detected:

account:
· base.menu_action_currency_form

association:
· base.menu_association
· base.menu_event_config
· base.menu_report_association

base_action_rule:
· base.menu_base_action_rule_admin

base_calendar:
· base.menu_calendar_configuration

crm:
· base.menu_sales
· base.menu_import_crm
· base.menu_sale_config
· base.menu_base_partner
· base.menu_crm_config_lead
· base.menu_crm_config_opportunity
· base.menu_sale_config_sales
· base.next_id_64

crm_claim:
· base.menu_project_report
· base.menu_aftersale

crm_helpdesk:
· base.menu_project_report
· base.menu_base_partner
· base.menu_aftersale

event:
· base.menu_event_main
· base.menu_marketing_config_root
· base.menu_report_association

hr:
· base.menu_crm_case_job_req_main

hr_recruitment:
· base.menu_crm_case_job_req_main

idea:
· base.menu_tools
· base.menu_lunch_survey_root

marketing:
· base.marketing_menu

marketing_campaign:
· base.menu_report_marketing

membership:
· base.menu_association
· base.menu_marketing_config_association
· base.menu_report_association

mrp:
· base.menu_mrp_root
· base.menu_mrp_config

multicompany:
· base.menu_action_inventory_form

plugin_outlook:
· base.menu_base_config_plugins

plugin_thunderbird:
· base.menu_base_config_plugins

product:
· base.menu_sale_config_sales
· base.menu_product


product_margin:
· base.next_id_73

project:
· base.menu_main_pm
· base.menu_definitions
· base.menu_project_config_project
· base.menu_project_report
· base.menu_definitions
· base.menu_project_config

project_long_term:
· "base.menu_project_long_term

purchase:
· base.menu_purchase_root
· base.menu_procurement_management_supplier_name
· base.next_id_73

sale:
· base.menu_base_partner
· base.menu_product
· base.menu_invoiced
· base.next_id_64
· base.menu_base_partner
· base.menu_base_config
· base.menu_sale_config

subscription:
· base.menu_tools
· base.menu_lunch_survey_root

survey:
· base.menu_tools
· base.menu_lunch_reporting
· base.next_id_10

I know that there are some modules that redefine menus because you
wanted in the past reduce the coupling between modules, but these are
the only solutions I see:

1. Set again some dependencies. Not desirable.
2. Create glue modules with the shared menus that are installed as dependencies of the others. Not the best, but it works.
3. Put that menus definitions on base, and add an active field on menus that allows to hide some menus. On modules that need this menu, you would define the menu again with active flag set to True, and translations will be already correct.
4. A variation of the last one, as all these cases are shared root menus, is that on web client, if there is a root menu that doesn't have any children, you can hide it. Less elegant.
5. At last, develop a method, as commented on the other bug report, to handle translation with foreign modules IDs. The costliest (on development and processing time), but the best to avoid any problem.

Let me know if you want me to help you on the MP.

Regards.

** Affects: ocb-server
     Importance: Undecided
         Status: New

** Summary changed:

- [6.1/7.0/trunk] Menu translations doesn't work after installation module installation because they have ID referenced as "base.xxx"
+ [6.1/7.0/trunk] Menu translations doesn't work after module installation because they have ID referenced as "base.xxx"

-- 
You received this bug notification because you are a member of OpenERP
Community Backports Team, which is subscribed to OpenERP Community
Backports (Server).
https://bugs.launchpad.net/bugs/1303918

Title:
  [6.1/7.0/trunk] Menu translations doesn't work after module
  installation because they have ID referenced as "base.xxx"

Status in OpenERP Community Backports (Server):
  New

Bug description:
  As seen on bug #1294887, some menus doesn't appear translated because
  their definitions on XML have an ID with reference to the base module,
  so that translation export tool include them on base translation file,
  not on each module. In this serie of consequences, only loading base
  module loads these translations, but on the base loading, translations
  are not loaded because the elements don't exist. The only way to
  handle this is to install module (for example purchase), and then
  update base module again.

  An easy solution to this is to rename these IDs to another ones, and
  it's very interesting that this lands on trunk before the v8 debuts,
  because this change is not easy to be done on an stable branch.

  This is the complete list of menus with this problem that I have
  detected:

  account:
  · base.menu_action_currency_form

  association:
  · base.menu_association
  · base.menu_event_config
  · base.menu_report_association

  base_action_rule:
  · base.menu_base_action_rule_admin

  base_calendar:
  · base.menu_calendar_configuration

  crm:
  · base.menu_sales
  · base.menu_import_crm
  · base.menu_sale_config
  · base.menu_base_partner
  · base.menu_crm_config_lead
  · base.menu_crm_config_opportunity
  · base.menu_sale_config_sales
  · base.next_id_64

  crm_claim:
  · base.menu_project_report
  · base.menu_aftersale

  crm_helpdesk:
  · base.menu_project_report
  · base.menu_base_partner
  · base.menu_aftersale

  event:
  · base.menu_event_main
  · base.menu_marketing_config_root
  · base.menu_report_association

  hr:
  · base.menu_crm_case_job_req_main

  hr_recruitment:
  · base.menu_crm_case_job_req_main

  idea:
  · base.menu_tools
  · base.menu_lunch_survey_root

  marketing:
  · base.marketing_menu

  marketing_campaign:
  · base.menu_report_marketing

  membership:
  · base.menu_association
  · base.menu_marketing_config_association
  · base.menu_report_association

  mrp:
  · base.menu_mrp_root
  · base.menu_mrp_config

  multicompany:
  · base.menu_action_inventory_form

  plugin_outlook:
  · base.menu_base_config_plugins

  plugin_thunderbird:
  · base.menu_base_config_plugins

  product:
  · base.menu_sale_config_sales
  · base.menu_product

  
  product_margin:
  · base.next_id_73

  project:
  · base.menu_main_pm
  · base.menu_definitions
  · base.menu_project_config_project
  · base.menu_project_report
  · base.menu_definitions
  · base.menu_project_config

  project_long_term:
  · "base.menu_project_long_term

  purchase:
  · base.menu_purchase_root
  · base.menu_procurement_management_supplier_name
  · base.next_id_73

  sale:
  · base.menu_base_partner
  · base.menu_product
  · base.menu_invoiced
  · base.next_id_64
  · base.menu_base_partner
  · base.menu_base_config
  · base.menu_sale_config

  subscription:
  · base.menu_tools
  · base.menu_lunch_survey_root

  survey:
  · base.menu_tools
  · base.menu_lunch_reporting
  · base.next_id_10

  I know that there are some modules that redefine menus because you
  wanted in the past reduce the coupling between modules, but these are
  the only solutions I see:

  1. Set again some dependencies. Not desirable.
  2. Create glue modules with the shared menus that are installed as dependencies of the others. Not the best, but it works.
  3. Put that menus definitions on base, and add an active field on menus that allows to hide some menus. On modules that need this menu, you would define the menu again with active flag set to True, and translations will be already correct.
  4. A variation of the last one, as all these cases are shared root menus, is that on web client, if there is a root menu that doesn't have any children, you can hide it. Less elegant.
  5. At last, develop a method, as commented on the other bug report, to handle translation with foreign modules IDs. The costliest (on development and processing time), but the best to avoid any problem.

  Let me know if you want me to help you on the MP.

  Regards.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ocb-server/+bug/1303918/+subscriptions