Main idea of this commit is to simplify the various options of
ir.actions.server model. Purpose is to make it a simple tool to
execute some actions or python code. This has two main consequences
* create and update server actions are simplified to update only the
current record. Complex options can always be achieved by python code
instead of error-prone option building mechanism;
* condition of server actions is removed. If a condition is necessary it
can either be included in a code server action, or integrated in an
automated action;
This commit features :
* remove 'client_action' server action type. Indeed this can be achieved
with a code server action returning an action;
* remove 'condition' on ir_actions_server model. From now on conditions
and triggers are managed in server action code or using automated
or scheduled action;
* clean 'create and copy a record'. Create and link are the proposed
options. Copy of the record or of a selected record is removed. Link
is simplified by removing the parsed expression that allowed complex
path update. It is simpler to write code than write python-like
expression in char fields;
* remove 'use_write' options. It now simply updates a record;
* remove 'write_expression' as it is replaced by code actions;
* remove 'ref_object' not used anymore with the removal of "choose
a record";
* remove helper to build an expression not used anymore with the removal
of "write expression";
* remove object ID finder;
* removed template display when choosing an email template; just go
on the template if you want more details;
* refactor server action form view to reflect changes. It will be used
in future commits as base view for automated and scheduled actions;
* add 'sequence' in list view;
* add new 'usage' selection field allowing to distinguish which model
uses the server action. Indeed as server action will soon be used
in scheduled or automated actions having a clue about the usage
is always helpful;
Thanks to @fpodoo for the original idea and preliminary work. Thanks to
@jpr-odoo for first developments. Thanks to @jem-odoo and @rco-odoo
for reviewing.
The JS widget is simplified, which a cleaner approach.
For the rendering part:
- the server reads the data
- the JS widget formats/organizes the data
- the template renders the data prepared by the widget
Quick summary of the modifications:
1. The associated field is a text field which contains JSON-encoded
data. The data are read server-side, and not client-side anymore.
2. The widget is an AbstractField, no need of ReinitializeWidgetMixin
anymore. No use of the FieldMonetary widget directly, but use a similar
format_value instead (inspired by ShowPaymentLineWidget).
3. Data formatting (call to format_value) is done in the widget, not in
the template anymore. This seems to be the standard way of doing, since
lunch was the only module where format_value was in the template and not
in the widget.
4. The addition of an order line is cleaner since all necessary data
are prepared server-side.
* Since the user_id field is required, it was impossible to delete
user when he had 'lunch.order' or 'lunch.cashmove'.
We removed required arguments on 'user_id' fields in model and set
"required='1'" on the fields in the view.
* There was a 'ondelete="cascade"' on 'order_line_ids' which does
nothing because it's not supported on One2many fields.
Add a link in the general settings to access easily the default_user form view in order to modify the default access rights
The default_user manager rights declarations in all the applications have been move in a noupdate="1" definition to avoid the manual configuration overwrittings
Christophe Simonis