External layout for reports can be customized. 4 Layout are currently
proposed, selectable from General Settings.
An onboarding popup is shown to select the layout to used if none has
been shown nor a company logo chosen.
Joint works by Fabien Pinckaers, Antony Lesuisse and Christophe Simonis.
Design by Csaba Fazekas.
Remove field 'display_on_footer' to stop displaying
account journal on report documents.
As the field is removed but also used in payment to
generate default 'Thanks Message', put a new field
on account.journal in payment module, to keep the
role 'display_on_footer' had in payment.
The onchange code calls the variable 'partner' before assignement,
this error comes from the migration in rev: https://github.com/odoo/odoo/commit/d45996c9
We fix it by calling the right 'self.partner_id' variable
It was checking the partner ID wasn't the public user ID, instead of the public
user's partner ID.
Date domain was also no applied correctly.
The action has been transformed into python method to have
access to both flexible datetime constraints + references.
Menuitem took the name of the action as it didn't have one himself.
Action's name got changed but menuitem didn't need to change, so a name
was added for the menuitem.
These `end` migration script will be executed when all modules have
been updated and models setup.
Also accelerate the search of migration scripts, speeding up registry
loading.
To reproduce:
- Configure an external payment provider (e.g. Ingenico) with "Authorize
& capture the amount, confirm the SO and auto-validate the invoice on
acquirer confirmation"
- Create a quotation with a product linked to a subscription
- Send the link to the customer
- Click on "Accept & Pay", use the configured provider
The SO is confirmed, but the invoice is not generated.
By calling `action_confirm` in the callback of the transaction, we
validate the SO before `form_feedback` is called. Therefore, the method
`_confirm_so` will do nothing since the SO is not in state 'draft' or
'sent' anymore.
The solution is to manually call `_confirm_so`instead of
`action_confirm`. This is necessary to do it at this moment since we
might not go through `form_feedback` (e.g. if we pay thanks to wire
transfer).
opw-694273
Before this commit, the field `web_icon_data` was a computed field
that depended on `web_icon` (which either specify a path to an image
or an icon).
We can now directly set the image binary value on the field.
The previous behaviour in which the binary is computed based on the
path is kept at the menu creation/edition, but the field is not `compute`
anymore.
This commit simplifies server code execution by allowing only server
actions to execute code. Scheduled actions (ir.cron) and automated
actions (base.action.rule renamed to base.automation) now delegate all
code execution to their own server action, using inheritance. Those
models now contain only fields related to cron details for scheduled
actions, or triggers and filters for automated actions.
Server actions have been simplified. Main options stay the same but
complex options in creation / update have been removed. Those should
be done using code-based server actions. A server action type to add
followers has been added.
Views have been updated accordingly. Base form view of server action
is used as a base for scheduled and automated action. Editing a cron
or an automated action looks like editing a server action with some
added fields.
Thanks to @fpodoo for the original idea and preliminary work. Thanks to
@jpr-odoo for first developments and @tivisse for improving and cleaning
the work. Thanks to @jem-odoo and @rco-odoo for reviewing.
Purpose of this commit is to continue to clean server actions, scheduled
actions and automated actions. Server actions hold code execution and
automated actions hold triggers and conditions.
This commit make automated action inherits from ir_actions_server.
Automated actions do not hold several server actions anymore. Instead
each new automated action creates its own server action holding the code
or actions to perform. Automated actions that held several server actions
should now simply use a server action of type multi. This commit also
features:
* rename 'kind' field to trigger
* remove 'act_user_id' as this should be done by the server action itself
not the automated action. This can be achieved using a write or code
server action;
* remove 'act_followers' as this is replaced by a followers server action;
* use a primary form view inherited from server action. This way automated
actions use the same base form as server actions with triggers and
conditions added;
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.
Purpose of this commit is to remove the link between Hr Contracts and
base automation. This has two consequences
* automated actions used to compute contracts state are transformed
into scheduled actions. Crons will do the job just as fine;
* option to use employee contract in automated actions is removed
and put in its own bridge module;
This allows to remove the dependency between the two addons.
CRM module depends on base automation only to have some automated
actions as demo data. To avoid having unnecessary dependencies
automated action demo data have been removed. This allows to remove
the dependency between CRM and base automation.
First step towards cleaning and improving automated actions is to
correctly name things. base_action_rule module is therefore renamed
to base_automation. Model is also renamed to base.automation.
The purpose of this commit is to handle code execution only in server
action and delegate schedule management to ir_cron model.
ir.cron model now inherits from ir.actions.server. Fields model, function
and args are removed as well as the logic to handle them. There is no
more code manipulation and evaluation in ir_cron, only a call to the run
method of ir.actions.server.
Cron form view use server action form view as primary view. This way
automated actions use the same base form as server actions with
cron details added.
Thanks to @fpodoo for the original idea and preliminary work. Thanks to
@jpr-odoo for first developments. Thanks to @jem-odoo for reviewing.
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.
This field is now informative only and not used through the codebase. As
an usage field could be defined on various inheriting ir.actions.*
models, let us remove it from the base model and give some freedom
to sub-models.
* use selection and selection_add to replace old indirection for state
field and ease code understanding
* update various strings and helps
* update Python code helper to match new API changes, notably model,
record and records being recordsets
Nicolas Martinelli