Before this commit, the administrator of a channel may easily unsubscribe
by accident from the channel.
With this commit, there is a confirmation dialog for the administrator of
the channel when he leaves it. This should prevent most accidental leaves
from the administrator.
Task-ID 1835641
The file report_invoice_view.xml was deleted in the commit 762adedece, but I forgot to remove it from the manifest.
This commit fixes it.
Task: 53996
PR #25209
This is needed because some reports we want to add later on, need to have
the address field on the left or following a given format.
Hence we moved the address div from each existing report on to the main report
template itself, Since some reports uses up until 3 addresses, we have defined
an area for the main address that each report can set (address used on the
envelope's window for sending). The any other extra address, or additional
information should be defined in the 'information_block' div
Was part of task: 35289
Was part of PR #25472
Create new methods on `BaseModel` to create records with given xml ids in
batch. Those methods replace the methods `_update` and `_update_dummy` of
model 'ir.model.data', which are now deprecated.
Adapt XML and CSV import code to create records in batch.
Commit dc1681b1 did change the name of the inventory creation from
direct qty update, but test still tries to compare the product.name
closesodoo/odoo#25948
In 11.0 7e724f96c5 is_product_variant has been introduced back (it was
removed in 10.0 b747b05fa). But related of _inherits are computed on the
related model so is_product_variant would always be false.
Without fix, added test fails with:
AssertionError:
Items in the first set but not the second: True, Items in the second
set but not the first: False, Product variants are variants
fixes#26961
related to opw-1814973
closes#27163
Before this commit, if you create an automated action with trigger 'on_change'
it was not called because the run() function don't have active_id.
Now if we have onchange_self in the context but not active id, we call the
function nevertheless. (withtout active_id in context!)
closesodoo/odoo#27167
- Create a Customer location (CL) and set a Company on it
- Configure Product A in FIFO / Perpetual
- Receive 2 Unit(s) of A in Stock
- Create an Internal Transfer
1 Unit(s) of Product A
Source location: Stock
Destination Location: CL
- Validate
The Inventory Valuation report incorrectly retrieves a quantity of 2 in
stock instead of 1.
The error is first due to a misconfiguration: the CL should not have a
Company set. However, we should not take into account any quantity in a
customer location, even if there is a Company set.
opw-1884675
opw-1884835
closesodoo/odoo#27145
Make sure that the company is not set on the customer and supplier
locations of the demo data. Otherwise, any quant in these locations will
be set a `company_id`, which is incorrect (e.g. valuation report will be
incorrect).
opw-1884835
closesodoo/odoo#27144
In ac1e187ee some unecessary code and RPC were removed by ignoring
attachments in the sidebar when they would never be shown.
But there was an regression since `updateEnv` function would not
longer call redraw (which is also called in _super function).
report: https://github.com/odoo/odoo/commit/ac1e187eea3#r30569171
related to opw-1865736
closes#27146
- Open a partner view, click on Action > Partner Review
- Switch to another partner
- Click again on Action > Partner Review
The Google Doc file of the second partner is the same than the first
partner.
This is due to `_onGoogleDocItemClicked` which is always called with the
same `resID`, i.e. the `resID` used at `start`.
We retrieve the active ID at each click instead.
opw-1882068
closesodoo/odoo#27132
Activate the group in the sale module: Sections on sale orders
Print an invoice
Before this commit, there were twice the same table filled with the invoice lines
After this commit, only one table and the right one is printed
OPW 1885549
closesodoo/odoo#27137
Steps to reproduce the bug:
On a new db, just launch:
./odoo-bin --addons-path=../enterprise,./addons --test-enable -d s11 -i l10n_be,account_accountant,stock,sale_management,purchase
An error occured in test_02_check_mto_chain due to the supplier taxes set on the product.
opw:1878341
closesodoo/odoo#27069
We clarify the `stock.quant.package` view to highlight the difference
between the case where the content is retrieved from the move lines or
the quants.
Otherwise, this is confusing for a user who sees the same record with
the same view, but not the same content.
opw-1883714
closesodoo/odoo#27098
Use case: have a partner in fr_FR while operating with a user in en_US
Create a SO for that partner
add a product which name is translated in french
Before this commit, the description of the sale order line takes the
*untranslated* name of the product
After this commit, it takes the *translated* name of the product
The issue was due to a limitation of sudoing within an onchange for related fields
(typically the case of product.product.name)
In this case, values that are missing in the cache are retrieved from another one
In our case:
First, _onchange_product_id_check_availability triggers the evaluation
of product.name as sudo (later in the stack), without lang in context
Second, the function that actually uses the product.name (product_id_change)
retrieves the value found before from the 'wrong' cache
OPW 1863305, 1884106
closes#27031
- Create a PO with 5 units of A and 10 units of B
- Receive the products
- Return the picking, but return 12 units of A and 10 units of B
The first picking (done state) will contain:
- 7 units of A, 0 qty done => it is an extra move
- 10 units of B, 10 qty done
But another picking (not done) is created, with
- 5 units of A, 12 qty done
The core of the issue is that the `origin_returned_move_id` is not
copied on the extra move. Therefore, it is not merged by `_merge_moves`
since the latter field is in the list of
`_prepare_merge_moves_distinct_fields`.
opw-1882959
- Set the product A in FIFO, real-time valuation
- Receive 5 units @ 2000 each
- Create a landed cost of 1000, apply on the picking
=> the cost of A is 2200
- Sell one unit
- Create another landed cost of 1000, apply on the same picking
The cost of A is 2360, while one expects 2400.
The value of the move after the second landed cost is computed as:
value = previous value + prorata of landed cost 2
= 11000 + (1000 * 4/5)
= 11800
This is not correct. The whole value of the second landed cost should be
taken into account for the `value` field. The prorata is only useful for
the field `remaining_value`.
opw-1878229
When localisation modules such as l10n_no are installed, the test
TestAngloSaxonCommon broke.
We isolate the test more by setting the right accounts on the products to make
the test pass.
This is useful for odoo.sh clients that install localisation modules and see the
tests break.
opw 1881014
When a sale is done on the website, a corresponding sale order is created in the
backend. By default the salesperson and sales team associated to the sale are as
defined on the website.
When we prepare values, we fallback on the partner sales team in a way that is
coherent with the way it falls back on the partner for the salesperson.
opw 1882640
Have the main company (A) with the public user
Have an invoice in company B
Make a brand new browser access the invoice with the token
Before this commit: the token link ended up asking the customer to login,
eventhough it wouldn't if the invoice were in company A
After this commit: the whole payment with access token flow works as expected.
OPW 1879999
closes#26744
In this commit we improve templates used in nearly all odoo addons. Purpose
of this commit is to have templates that embed or use standard Odoo email
layouts to make them look modern and have a common style across all emails.
Main guidelines
* better use of div / p / br to try to lessen layout issues, especially
when updating templates using the editor;
* correctly sequence the templates fields definition;
* correctly set templates values notably auto_delete and user_signature
fields to avoid confusion;
* correctly layout the email content using light notification email. It
can either propagate the layout choice through various send mail methods
or directly embed the styling in the templates for more technical or
complex templates;
* use email_formatted computed field when possible to avoid having hand-made
from / to addresses;
* fix various typos and improve subjects when necessary;
Content of emails is not necessarily updated as the purpose of this task is
about styling, not content itself.
This merge also contains some additional code allowing to layout email sent
through the send_mail of mail.template and the send_mail of survey.compose.
message. It allows to strip the layouting part of the email and keep only the
content in the template body. Some technical templates keep the full layout
to keep the possibility of easily send them through various pieces of code.
This merge is linked to main task 1868112 and closes main PR #25889. It is the
summary and review of several tasks and several PRs:
* task ID 1843361 and closes PR #25287
* task ID 1843171 and closes PR #25293
* task ID 1843395 and closes PR #25294
* task ID 1843122 and closes PR #25295
* task ID 1843360 and closes PR #25299
* task ID 1843224 and closes PR #25313
* task ID 1843151 and closes PR #25346
* task ID 1843376 and closes PR #25349
* task ID 1841503 and closes PR #25388
* task ID 1843136 and closes PR #25412
Thanks to all contributors and testers for this task !
In this commit we improve templates used in website_slides. Purpose of this commit
is to have templates that embed or use standard Odoo email layouts to make
them look modern and have a common style across all emails.
Main guidelines
* better use of div / p / br to try to lessen layout issues, especially
when updating templates using the editor;
* correctly sequence the templates fields definition;
* correctly set templates values notably auto_delete and user_signature
fields to avoid confusion;
* correctly layout the email content using light notification email. It
can either propagate the layout choice through various send mail methods
or directly embed the styling in the templates for more technical or
complex templates;
* use email_formatted computed field when possible to avoid having hand-made
from / to addresses;
* fix various typos and improve subjects when necessary;
Content of emails is not necessarily updated as the purpose of this task is
about styling, not content itself.
This commit is linked to task ID 1843376 (and 1868112) and closes PR #25349
(and #25889).
In this commit we improve templates used in website_sale. Purpose of this commit
is to have templates that embed or use standard Odoo email layouts to make
them look modern and have a common style across all emails.
Main guidelines
* better use of div / p / br to try to lessen layout issues, especially
when updating templates using the editor;
* correctly sequence the templates fields definition;
* correctly set templates values notably auto_delete and user_signature
fields to avoid confusion;
* correctly layout the email content using light notification email. It
can either propagate the layout choice through various send mail methods
or directly embed the styling in the templates for more technical or
complex templates;
* use email_formatted computed field when possible to avoid having hand-made
from / to addresses;
* fix various typos and improve subjects when necessary;
Content of emails is not necessarily updated as the purpose of this task is
about styling, not content itself.
This commit is linked to task ID 1843171 (and 1868112) and to PR #25293
(and #25889).
Website quote gave the possibility to define an email template to use
when sending a quotation / sale order by email. This was done at a time
where doing correct templates in sale was difficult to do / implement.
Now send by email template is completely inside sale module and should
cover all use cases.
Having a settings to customize it is not considered as necessary as it
can be customized easily.
This commit is linked to task ID 1843171 (and 1868112) and to PR #25293
(and #25889).
In this commit we improve templates used in website_mail_channel. Purpose of
this commit is to have templates that embed or use standard Odoo email layouts
to make them look modern and have a common style across all emails.
Main guidelines
* better use of div / p / br to try to lessen layout issues, especially
when updating templates using the editor;
* correctly sequence the templates fields definition;
* correctly set templates values notably auto_delete and user_signature
fields to avoid confusion;
* correctly layout the email content using light notification email. It
can either propagate the layout choice through various send mail methods
or directly embed the styling in the templates for more technical or
complex templates;
* use email_formatted computed field when possible to avoid having hand-made
from / to addresses;
* fix various typos and improve subjects when necessary;
Content of emails is not necessarily updated as the purpose of this task is
about styling, not content itself.
This commit is linked to task ID 1843361 (and 1868112) and to PR #25287
(and #25889).
In this commit we improve templates used in website_forum. Purpose of this
commit is to have templates that embed or use standard Odoo email layouts to
make them look modern and have a common style across all emails.
Main guidelines
* better use of div / p / br to try to lessen layout issues, especially
when updating templates using the editor;
* correctly sequence the templates fields definition;
* correctly set templates values notably auto_delete and user_signature
fields to avoid confusion;
* correctly layout the email content using light notification email. It
can either propagate the layout choice through various send mail methods
or directly embed the styling in the templates for more technical or
complex templates;
* use email_formatted computed field when possible to avoid having hand-made
from / to addresses;
* fix various typos and improve subjects when necessary;
Content of emails is not necessarily updated as the purpose of this task is
about styling, not content itself.
This commit is linked to task ID 1843224 (and 1868112) and to PR #25313
(and #25889).
In this commit we improve templates used in website_crm_partner_assign.
Purpose of this commit is to have templates that embed or use standard Odoo
email layouts to make them look modern and have a common style across all
emails.
Main guidelines
* better use of div / p / br to try to lessen layout issues, especially
when updating templates using the editor;
* correctly sequence the templates fields definition;
* correctly set templates values notably auto_delete and user_signature
fields to avoid confusion;
* correctly layout the email content using light notification email. It
can either propagate the layout choice through various send mail methods
or directly embed the styling in the templates for more technical or
complex templates;
* use email_formatted computed field when possible to avoid having hand-made
from / to addresses;
* fix various typos and improve subjects when necessary;
Content of emails is not necessarily updated as the purpose of this task is
about styling, not content itself.
This commit is linked to task ID 1841503 (and 1868112) and to PR #25388
(and #25889).
In this commit we improve templates used in survey. Purpose of this commit
is to have templates that embed or use standard Odoo email layouts to make
them look modern and have a common style across all emails.
Main guidelines
* better use of div / p / br to try to lessen layout issues, especially
when updating templates using the editor;
* correctly sequence the templates fields definition;
* correctly set templates values notably auto_delete and user_signature
fields to avoid confusion;
* correctly layout the email content using light notification email. It
can either propagate the layout choice through various send mail methods
or directly embed the styling in the templates for more technical or
complex templates;
* use email_formatted computed field when possible to avoid having hand-made
from / to addresses;
* fix various typos and improve subjects when necessary;
Content of emails is not necessarily updated as the purpose of this task is
about styling, not content itself.
This commit is linked to task ID 1843224 (and 1868112) and to PR #25313
(and #25889).
This commit adds possibility to add a notification layout when sending
an email in survey using their specific composer. Purpose of this task is to
allow to send some technical template-based emails using the default
notification layouts defined in mail. It allows to avoid redefining the whole
layout in the template itself. This way email body content is simpler.
This commit is linked to task ID 1843224 (and 1868112) and to PR #25313
(and #25889).
In this commit we improve templates used in repair. Purpose of this commit
is to have templates that embed or use standard Odoo email layouts to make
them look modern and have a common style across all emails.
Main guidelines
* better use of div / p / br to try to lessen layout issues, especially
when updating templates using the editor;
* correctly sequence the templates fields definition;
* correctly set templates values notably auto_delete and user_signature
fields to avoid confusion;
* correctly layout the email content using light notification email. It
can either propagate the layout choice through various send mail methods
or directly embed the styling in the templates for more technical or
complex templates;
* use email_formatted computed field when possible to avoid having hand-made
from / to addresses;
* fix various typos and improve subjects when necessary;
Content of emails is not necessarily updated as the purpose of this task is
about styling, not content itself.
This commit is linked to task ID 1843395 (and 1868112) and to PR #25294
(and #25889).
In this commit we improve templates used in purchase. Purpose of this commit
is to have templates that embed or use standard Odoo email layouts to make
them look modern and have a common style across all emails.
Main guidelines
* better use of div / p / br to try to lessen layout issues, especially
when updating templates using the editor;
* correctly sequence the templates fields definition;
* correctly set templates values notably auto_delete and user_signature
fields to avoid confusion;
* correctly layout the email content using light notification email. It
can either propagate the layout choice through various send mail methods
or directly embed the styling in the templates for more technical or
complex templates;
* use email_formatted computed field when possible to avoid having hand-made
from / to addresses;
* fix various typos and improve subjects when necessary;
Content of emails is not necessarily updated as the purpose of this task is
about styling, not content itself.
This commit is linked to task ID 1843151 (and 1868112) and to PR #25346
(and #25889).
In this commit we improve templates used in portal. Purpose of this commit
is to have templates that embed or use standard Odoo email layouts to make
them look modern and have a common style across all emails.
Main guidelines
* better use of div / p / br to try to lessen layout issues, especially
when updating templates using the editor;
* correctly sequence the templates fields definition;
* correctly set templates values notably auto_delete and user_signature
fields to avoid confusion;
* correctly layout the email content using light notification email. It
can either propagate the layout choice through various send mail methods
or directly embed the styling in the templates for more technical or
complex templates;
* use email_formatted computed field when possible to avoid having hand-made
from / to addresses;
* fix various typos and improve subjects when necessary;
Content of emails is not necessarily updated as the purpose of this task is
about styling, not content itself.
This commit is linked to task ID 1843361 (and 1868112) and to PR #25299
(and #25889).
Shubham Johar