Now, the form FieldDomain has an option "dialog" which allows to force
the domain *edition* in a new dialog. This allows the field to be
positioned in smaller area of the form view in some contexts.
The FieldDomain is composed of a DomainSelector widget and a button
which allows to see the records which match the domain (or an error
message if the domain is wrong).
The button was placed below the domain selector. Now, in edit mode,
it is placed at the top-right of the domain selector, saving some
vertical space.
Before this commit, the DomainSelector had to be instanciated with an
array-typed value which forced the user to use (and import) the pyeval
module. Now, the conversion to array is done in the DomainSelector.
This commit introduces a web.domainUtils module allowing to do the
convertion array -> string and string -> array of a domain.
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.
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
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.
qsm-odoo