If website is installed but not used/enabled for the current controller,
overridden methods like _get_converters will *still run* for the controller's
dispatch.
This means a ModelConverter used in a controller with website installed but
not enabled will use website.models.ir_http.ModelConverter, not
base.ir.ir_http.ModelConverter, and base's args postprocessing will *not* be
able to convert the placeholder object to a real UID, only website's
postprocessing can do so.
And as far as I can see there's no reason to skip the URL building validation
either, only the multilang stuff relies on and requires that the controller be
website enabled (and in fact that it be multilang enabled), so only *that*
should be gated behind a flag.
Also always call super(), there's no reason not to and others might add args
to postprocess on base rather than website, ending up after website in the
MRO.
[MERGP] Inline Searchview
This task split the searchview in two parts: SearchView and SearchViewDrawer. The drawer is displayed inside the main view and the searchview stays in place. It also changes the scrolling behavior of the web client: the main view area can scroll without affecting the UI (so the various menus stays in place)
Because of this, other large changes have been made:
the drawer has been redesigned,
the Custom Filter widget has been split in two (Custom Report and SaveCurrentFilter),
the main view is now scrollable, so the UI stays in place and only the view can change
The text 'Group By...' has been changed into 'Group By' (most addons had to be modified)
bootstrap classes are used when it makes sense (for example, badge)
the left menu is also scrollable (separately from the main view)
It is likely that some stupid bugs have been introduced. Please don't hurt me.
sale_order module override state field of sale.oder (sale.sale.py) and forgot to reset the track_visibility, therefore sale orders state changes are no longer tracked once this module installed.
This will make sure already processed rules are persisted
in case a timeout occurs while processing the next ones,
ensuring that *some* progress can be made in most cases.
A safety guard already in place prevents the recursive
trigger of rules while another rule is being executed,
as a simple measure to prevent endless loops.
This guard was missing when processing time-based rules.
A programming error introduced at rco@openerp.com-20121220142445-emzzvhlw400q37c9
fails to properly check when a rule has already been executed in the past.
Time-based rules should only be executed if the trigger date is in the past and:
- either they never executed before
- or the last execution date is older than the trigger date
Executing a rule always updates the `last_run` value, which would
always force a useless registry reload to occur. Only signal the
change if the rule applies to a model that was not previoulsy
monitored for base action rules.
When @primary="True" is present on <template> tag, we'll set
the t-name to the full canonical xmlid of current template (@id)
Providing a "kind of" clone mode for templates.
The field note on account.fiscal.position and account.fiscal.position.template should not be translatable in classic modules.
The l10n_multilang module is intendend to make chart of accounts multilang and is the place to set translate=True
Xavier Morel