The @groups attribute in qweb views was not rendered (even when matched by the
user), so editing a template with an @groups would either remove the whole
section (if the user didn't have the groups, fixed in previous commit) or only
removed the attribute itself making it visible to everybody (which ought be
fixed-ish by this commit).
If the current view uses @groups attributes (possibly in called templates),
the corresponding elements are rendered to a void (empty string in qweb). If
said user can edit the page, does so and saves a view section in which there's
a @groups to which he has no access, the element[@groups] is completely
removed from the template once saved, losing it.
If QWeb encounters an @groups to which the current user has no right during
rendering, have it request a no-RTE page, so the user can not RTE-edit the
page (or drop snippets in it).
[FIX] issues when uninstalling modules: unlink ir.action.todo which are related to actions which will be deleted (fix issues when uninstalling modules) + check for menu existence before displaying need action
[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.
Xavier Morel