Currently, the _recompute_tax_lines method is too long and there is no way to customize the taxes_map before move line creation. This commit adds a hook to be able to customize the tax dict values.
closesodoo/odoo#76431
X-original-commit: 748ac0764ae2f68dfd2a73ba273e2c194fad282b
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Let's make use of Many2oneReference as a better tool to link the model and the id.
closesodoo/odoo#70518
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If you modify an archived warehouse, it may happen that the associated operations get unarchived. Operations should be active only if their warehouse is active.
closesodoo/odoo#70607
X-original-commit: 63167ac8ae6ac08fa54a133ed9089dd872c7d73c
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
You may have inactive warehouses for some companies and then, when recreating missing warehouses, you try to create same warehouses for those companies, but you can't because there is an unique constraint.
closesodoo/odoo#62620
X-original-commit: 9b91f9d1bb41d05f445d745a9b8e5fa63edaf2a9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
PURPOSE
Be able to customize notification email values in a given model by overriding
a simple method instead of having to hijack the email creation process.
SPECIFICATIONS
Add a hook in mail.thread that can be overridden in specific addons, either
by model or globally by inheriting mail.thread.
Include _notify_email_headers in it so that it is correctly embedded in
model-specific values computation.
This removes the need to replace _notify_record_by_email long method in a
custom module.
Closesodoo/odoo#48213Closesodoo/odoo#50097closesodoo/odoo#50129
X-original-commit: 1ba8712d7a797cf2e821ae881cb1f1c4ea2fc11d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When a field is related, defining a selection or selection_add will
have no effect and the paramater is ignored.
Log a warning and fix all fields badly definied
Closesodoo/odoo#45716closesodoo/odoo#45832
Related: odoo/enterprise#8613
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Previous versions of this action had a context. It was removed at
odoo/odoo@2d3e6d7383 Set explicitly an empty context to
force the removal when upgrading the module. Fine tunning of
odoo/odoo@9346563009closesodoo/odoo#43319
X-original-commit: 63a5a795a57af0da3b7459e0acd83a247861eaf3
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The _get_report_values method is an api.model, not an api.multi (on a purely ORM
consideration, it should have no impact on the execution on standard
code).
closesodoo/odoo#39535
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Fine-tuning of a8dbbc029d1e86c84, similar to d76cd50f0e
Avoid error of 'user_type_readonly' referenced before assignment.
This can happen during database migration or if the module category is deleted.
closesodoo/odoo#38190
X-original-commit: cf1e5198e32e9239a6d3cbbfdc325dbd3e0952de
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Currently when creating an attachment in backend, history section holds
a "Creation: on" void line that is populated after create with "creation:
administator on 2019..." . This is quite ugly and not usability oriented.
Let us hide the history line while create information are not set, aka
before first save of record.
closesodoo/odoo#37940
X-original-commit: 9ef4cb3ada349b34ba8a5daa5ca9f9765bc43437
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some companies may have several locations with usage == 'inventory' and they would like to choose each time which adjustment location to use.
closesodoo/odoo#37022
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose of this commit is to use is_mail_thread field in a constraint
instead of manually checking classes. Field is also made visible on
model search and group to ease its use.
closesodoo/odoo#37867
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The previous change was done to solve a case of duplicated xmlids in
v12. By some confusion, both xmlids were changed in separated
commits. This new commit returns the original xmlid of one and assures
to avoid more confusions by adding 'settings' to the other.
Closesodoo/odoo#36885closesodoo/odoo#37755
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The view name is often not very informative, add the external id for a better
error
closesodoo/odoo#29473
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Previous versions of this action had a domain. It was removed at 2d3e6d7383
Set explicitly an empty domain to force the removal when upgrading the module
Similar to 2d03ed43a5closesodoo/odoo#34581
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Those two decorators are removed/deprecated since recent commits but
some references remained in the documentation.
api.guess and api.noguess is deprecated and removed since c552fb7a61closesodoo/odoo#35332
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Ensure the write method in account.journal is working with multiple records.
The for loop indicates it was the intention to be used on several records but
self was still used instead of journal
Some methods like _update_mail_alias work with an ensure_one
closesodoo/odoo#28246
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
There exists two actions for the same mode
The mrp_production_report action is used for the graph and pivot.
The reporting view does not need a form view, which can be displayed in the
operation action
Closes#25239
The action action_pos_config_pos is to configure the PoS config record.
No need to display a kanban as to launch a new PoS
action_pos_config_kanban is the one that display the kanban view
Closes#25239
It was possible to change manually the company of an asset, although its category would be belonging to another company and thus its depreciation lines and journal items also.
To tackle this problem, we set the company_id field of an asset as related to its category
Was PR #23498. Courtesy of Miquel Raïch
We want to force the tax template to be blank always, because multiple companies can potentially use this template to create taxes. We want consistency company-wise.
* In account.journal model, the domain of bank_account_id field was incorrectly comparing the partner_id with a res.company object
* When modifying the company of a bank journal, the company of the related res.partner.bank was changed without checking if it had a company and also its partner (account holder) was not changed.
Was PR #23480. Courtesy of Miquel Raich (Eficent)
mreficent