when plan workorder, cancelled/done workorders are taken in to account
when they block current workorder. In this fix, we ignore then when plan
workorder.
Task-3126569
closesodoo/odoo#114940
X-original-commit: 1b629659cb651c62fdd2c880ae591f9a9bb2e1eb
Related: odoo/enterprise#38020
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Wrong key was used to display the unit of measure in the BoM Overview,
leaving the cells empty.
closesodoo/odoo#114934
X-original-commit: a6eba909a8f2ab07ddb239b4b64e82d51f724e66
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
This issue was caught in Sentry.
The return type of the partner avatar for public users is `odoo.http.Stream`,
but the `route_wrapper` expects it to be `Response streamed`.
sentry-3929988311
closesodoo/odoo#114933
X-original-commit: 62ddfe0badf54375bc458bdb50cbcdbe4da5bbcd
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit will rename the font "Muli" to "Mulish" as it has been
renamed in Google Fonts.
closesodoo/odoo#114932
X-original-commit: c24602e882f87c361866a739459a9d6e3f4fc6ef
Related: odoo/design-themes#638
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When duplicating an analytic account, we want to make more explicit
which account is the duplicate and which one existed before.
task-3202027
closesodoo/odoo#114931
X-original-commit: d499b9da8ba1b46db0671f14658a55095c68921d
Signed-off-by: William André (wan) <wan@odoo.com>
- Create a product with a very long product description
- Add in a PO and print the RFQ
The description overlaps with the table header on the second page.
This is a known issue of wkhtmltopdf (see issues 1770 and 1524 for
example), and there is no known workaround. It can be avoided by
preventing the repetition of the header.
closesodoo/odoo#114916
Opw: 3208347
X-original-commit: cc5be8a907b2c3f33c6a62c5693726d757ffd113
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Amounts in the spredsheet Sales dashboards are displayed without their currency
even though the amounts are all correctly converted to the current
company's currency.
With this commit, amounts are displayed with their currency in the
dashboard, list view and default form view.
The hardcoded number format is removed on the dashboard cells to let
the automatic format do the job
Task 3167343
closesodoo/odoo#111702
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
The last view in the odoo codebase has just been converted to owl,
meaning that we no longer have legacy views. This allows us to
remove a lot of legacy view related code: the abstract elements on
which the legacy views were built, the compatibility layers that
allowed to deal with both owl and legacy views uniformly, legacy
widgets that were only used in those legacy views...
closesodoo/odoo#114893
Related: odoo/upgrade#4420
Related: odoo/enterprise#38005
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit changes the function isInvisible visibility to private on
the record, this means that outside the record, the modifiers need to be
evaluated.
Part-of task-id 3179751
closesodoo/odoo#114891
Related: odoo/enterprise#38009
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
This commit addresses a bug where the "description" field on the user
screen was not displaying properly. This fixes the formatting issue,
ensuring that the field is now properly displayed with appropriate line
breaks and spacing. Users can now view their description information as
intended.
closesodoo/odoo#114881
X-original-commit: 52858350a78856e7da444617dc2779a2f19688a0
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
If applied, this commit will solve the KeyError of 'list_ids'.
Before this commit
=======================
When there are no Mailing Lists available and add the snippet 'Newsletter block'
in the website with the template 'Form Subscription' and any user tries to
Subscribe to that form. It will raise an error like KeyError: 'list_ids'.
After this commit
========================
In this commit, checking keyword arguments which have list_ids in this or not if
list_ids not in that returns the error like 'Mailing List(s) not found!'
see - https://tinyurl.com/2n3o7s58
sentry - 3949183926
closesodoo/odoo#114871
X-original-commit: 360579977634c38c1cd6287c03e7c06796b408b1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Currently, all localizations of UoM fields are visible in all countries.
So in this commit, I have added a new compute field in UoM models, the field
contains comma-separated company's country codes, and I have used this field
for the hide/unhide fields.
closesodoo/odoo#112604
Related: odoo/enterprise#36572
Related: odoo/upgrade#4284
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before the fix, the compute function is set as a string in the `default`
parameter. Meaning that it will always be True because a non empty
string is truthy.
Fix by converting the field to be compute-editable, like the function
was designed to be.
closesodoo/odoo#114904
X-original-commit: 11121120b13fc7500ee720f10964de6b9a0373af
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
The main objective of this commit is to make checkboxes consistent
and fix their spacing issues.
Prior to these changes, the checkboxes on the `product_view` were
too close to their neighboring option labels, making it difficult to
know which checkbox to tick.
The new changes fixes inconsistencies in general such as undesired
hovering effects and the cursor behaviors on disabled inputs.
This commit also removes the margin in the checkbox template since the
padding from the checkbox wrapper compensates for the spacing between
the checkboxes and their respective labels.
Tweaking the selector in `settings_form_view.scss` to ignore boolean
field inputs allows us to get rid of max-width and margin overrides
introduced in commit b90059e936.
Most checkboxes were already falling under their labels on mobile, but
this change impacted those that were not. To address this issue, we
decided to consistently change the position of the checkboxes left to
their labels for small devices in form view.
This required slight adjustments to the `form_group.xml` template.
Still in form_view, for some of the specific checkboxes such as
`o_checkbox_optional_field` the changes in `form_controller.scss` are
made to mimic the new behavior for mobile sized screen.
However, if they are using the form_group template, their behavior
is unchanged at the moment.
Finally, even if these changes makes it better for most of them, some
checkboxes in `settings` still require some minor adjustments and will
be addressed in task-3113372.
task-3094083
closesodoo/odoo#114612
X-original-commit: ddb7574f97f11e69f0304c8bd8d55c2c53ab53fd
Related: odoo/enterprise#37887
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The `t-cache` used on the `<head>` of website.layout was wrong: it
depended on the use of debug=assets or not (added by [1]) while it
should at least also depend on debug=tests. This commit chooses to fix
the issue by not using the caching system in case any value of debug
is used.
This commit also comments this `t-cache` value.
Steps to reproduce:
- As a visitor, first visit the homepage without debug mode
- Now reach the homepage with ?debug=tests
=> You still don't have the tests assets
Worse (but unlikely in production of course):
- Create a fresh DB and first reach the homepage with debug=tests
=> Now all your visitors are damned to load the tests tours for no
reason (and you likely have lots of errors shown in your console).
[1]: https://github.com/odoo/odoo/commit/3061a484168ff21e3ae7e40ce691d299b63484a4
opw-3203912
closesodoo/odoo#114875
X-original-commit: 5efb637d880f82ea81bb64a0d091ffa7bdf7635b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Many of our users have a default OS/browser zoom of 150% when using a
1920x1080 (Full HD) screen. One cause is that this is the recommended
zoom when using Windows. Whatever the reason: many users have a
1920x1080 screen combined with a 150% zoom... and in that case, entering
edit mode would display the website as it would be on "mobile" devices.
This is because since [1], the website is actually reduced in size when
entering edit mode since an iframe is used, whose size is reduced by
the size of the right panel. Before [1], the right panel would be
*included* in the website which would appear reduced but using CSS rules
according to the full screen width (which also led to other issues but
this is in the past now).
The sidebar was actually 3px too wide. Reducing it from 291px to 288px
solves the issue (at least if the OS task bar is not anchored to the
left/right). Indeed 288px is 1920px / 150% - 992px, where 992px is the
current minimum width the screen must have for our websites to be in
"desktop" mode (below, columns break over multiple lines).
Notice that 1920px / 150% = 1280px which gives the minimum size of the
screen that will display the website in "desktop" mode in the editor if
no zoom is used, which seems like an acceptable value.
Note: reducing the sidebar width even further to support more devices or
more zoom / OS task bar configuration would be problematic as the
sidebar would become too small. It is currently kinda at both its
maximum and minimum authorized value.
We tried solutions to virtually "de-zoom" the website iframe to display
the website in "desktop" mode no matter what but this did not give great
results. On problematic devices, the user still has the possibility to
de-zoom its browser by himself.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#114873
X-original-commit: e3ab91188173a47bdc827d8f0e45efcf7b246a4a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: l10n_co_pos, l10n_fr_pos_cert, point_of_sale, pos_loyalty,
pos_mercury, pos_restaurant, pos_sale, pos_sale_product_configurator
This is a step in the direction of making the pos no longer depend on
the legacy environment.
closesodoo/odoo#114668
Related: odoo/enterprise#37906
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Prior to this commit, if the window was big enough to not be in mobile,
it could still be small enough so that the menu items overlap with the
systray item when the website client action was first mounted.
Steps to reproduce:
- Choose a language with long words (such as Slovak) or translate one of
website app menu terms to a word with more than 12 characters
- With the browser's dev tools set screen size to be responsive with a
resolution of 847 x 867
- Start odoo and go in the website app
- The menu items overlap with the systray items
This commit fixes that by not only re-rendering the navbar when the
website content is properly loaded (which was already done before) but
also by adapting it afterwards. However, to do so it copies the code
already present in the "web" navbar.
task-2687506
closesodoo/odoo#114869
X-original-commit: 690f420ceae799ed991f49afa405c917b3c101d2
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Since #91640, the locations on stock picking are editable except in `done` state. This can leads to misunderstanding if some stock move lines
are already created. The locations on stock picking act as default
values for stock move/ stock move lines. Validating a picking will
always use the location set on stock move lines even if those ones
differ from the picking. This commit adds a simple error message in
to address this situation.
Close#113486
opw-3148993
closesodoo/odoo#114868
X-original-commit: 3eeab703f4e36723eae6005cf4b966f20f1e62dd
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Current behaviour:
If you have a confirmed SO, with a `sale.order.line` that has a
`product_packaging_id`, and you write a new `product_packaging_id`,
the "Delivery Order" has 2 lines, 1 move with the old qty and the old
packaging, and another line with the difference of qty and the new packaging.
Same behaviour is present on purchase side.
Expected behaviour:
If you have multiple `stock.move.line` from the same `sale.order.line`,
they should be able to merge, when you changed the `product_packaging_id`.
Ex: If you edit an SOL from 1 pack of 10 to 1 pack of 20, we should have
1 move line with qty 20 in packs of 20, instead of 2 lines, one with qty 10
in packs of 10, and another line with qty 10 in packs of 20.
Same behaviour is expected on purchase side.
Steps to reproduce:
- Install Sales and Inventory
- Activate "Product Packaging" in Settings
- Create a new product with 2 types of packaging
- PackOf10 with quantity of 10
- PackOf20 with quantity of 20
- Create a SO with a new line that product, quantity 10
- Confirm the SO
- Edit the SOL with 1 pack of 20 (`product_uom_qty`=20)
- The "Delivery Order" has 2 lines, instead of 1 with the new packaging
Reason for the problem:
When saving the SO/PO, a new `procurement` is created which will create
a new `stock.move.line` with the new packaging. This will prevent the
lines to merge correctly, because they have different packaging.
Fix:
When writing the `product_packaging_id` on a `sale.order.line`/`purchase.order.line`,
we directly write the package on the `stock.move.line`,
before any `procurements` are created, so the generate move lines
can correctly be merged.
Affected versions:
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master
opw-3002612
closesodoo/odoo#114866
X-original-commit: 87ed4b2f6c9c36202a1a4f3de143f638cf38d047
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Before this commit, only the immediate parent of a selected node was
checked for HTML content support in order to determine the toolbar's
visibility. This led to incorrectly displaying the toolbar for fields
like the 'list-price' on an e-commerce product page, whose text content
is wrapped in an extra 'span' element inside the field's span element.
This commit fixes it by checking all of the node's ancestors up to the
editable root for the attributes that determine if a field supports HTML
content.
This commit also prevents a server error if the user somehow styles the
product's price (with ctrl+B for example. It's worth noting that such
style would not be kept in the saved version of the page).
lxml.HtmlElement's `text` property has `None` value if the span element
does not contain any text before its first child element
(see https://lxml.de/apidoc/lxml.html.html).
Therefore an element like `<span><strong>42.00</strong></span>` would result
in `None` when reading its `text` property.
The `text_content` method is more suitable for such task as it returns the
text content of an element and its children.
task-3188550
opw-3171669
closesodoo/odoo#114867
X-original-commit: 524ba7f89286aa03ed6a4da30177c9ce7018c59a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit adds a new service called "timesheet_uom", this service will
help to find the right component to use for the `timesheet_uom` widget
sicne this widget could be float, float_factor, float_toggle or
float_time widget. This service also adds the right formatter to use for
this widget to correctly format the value when the formatter is used
instead of mounting the component.
task-2702636
Part-of: odoo/odoo#108605
Before this commit, the default employee set in the context to create a
timesheet is unused in the create method.
This commit uses the context to set the employee when no user and no
employee are given in the vals parameter.
task-2702636
Part-of: odoo/odoo#108605
Before this commit, the `getRawValue` function was just used in the
kanban_record file and not exported and so it is impossible to use it
in another JS file. This function could be useful if the rawValue is
needed for just a subset of activeFields or just for one field and so
it is a bit overkill to use getFormattedRecord util for that.
This commit exports `getRawValue` function to be able to use it in
another JS file.
task-2702636
Part-of: odoo/odoo#108605
Before this commit, the `bool_or` and `bool_and` aggregations are not
managed in the mockServer.
This commit allows to use the `bool_or` and `bool_and` aggregators for
boolean fields in the read_group mock rpc.
task-2702636
Part-of: odoo/odoo#108605
Before this commit, the formatter used for `float_toggle` widget is
`formatFloat` function, but the `value` parameter should be computed
with the factor set on the widget. This calculation is also done in
`formatFloatFactor` function before calling the formatFloat function.
This commit uses the `formatFloatFactor` to uniform the code instead of
doing the calculation in 2 different sides (one in the widget and one
in the `formatFloatFactor`).
task-2702636
Part-of: odoo/odoo#108605
Before this commit, the aggregate function must be defined to be able
to correctly aggregate the sample data.
This commit searches the aggregate function in the fields definition
when no aggregate function is defined to a field in `fields` parameter
of the `read_group` method.
task-2702636
Part-of: odoo/odoo#108605
This commit moves `removeDomainLeaf` in domain.js to be able to use
the method everywhere in the JS Code and not only in the gantt view.
task-2702636
Part-of: odoo/odoo#108605
Before this commit, the relation is found in the fields of the record
of the component but the relation could also be in the props of the
component.
This commit uses the getter `relation` defined in the parent component
(Many2OneAvatarField) to search the relation in the props first and
then in the fields of the record is the relation is not defined in the
props.
task-2702636
Part-of: odoo/odoo#108605
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
Usecase to reproduce:
-2 products setup as Periodic valuation
- Create a PO to buy both products
- Receipt and create the bill
- Modify the price unit on both invoice line to create correction layers
The label on the journal items have the same label relative to only one
of the products. It should keep the same label than before the
confirmation.
closesodoo/odoo#114792
X-original-commit: 226ae25b5f93164f14c1e68ed8bc2ea8a48b4e27
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The colors of the stress days in the calendar were not adapted for the
dark mode, they were too bright and thus unreadable.
task-3216055
closesodoo/odoo#114796
X-original-commit: 0f60e0ac2c24998c2f792a55ae282d62df6b5f42
Signed-off-by: Kevin Baptiste <kba@odoo.com>
before this commit, enabling the mass editing for the
invoice and sale order tree view using the studio,
throws exception.
* install studio
* open sale order tree
* enable mass editing for the tree using studio app
* exception will be shown
after this commit, on enabling mass editing on this tree view, exception will not be shown.
closesodoo/odoo#114795
X-original-commit: 105cdc773f6673661d3fdf766084cbc85c97c589
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit adds a check to prevent saving a translation in a language that was not installed.
Upon adding a translation, the field "language" in the request was not checker,
allowing to add translation for language (or any strings as key) for a given field
This is not ideal and we want to prevent that, it can bloat the database for no reason.
opw-3208305
closesodoo/odoo#114793
X-original-commit: 89cd5ce88a0c666e811410e264e3cb474f9851c0
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
2-steps delivery. If there is already a backorder for the picking
out->customer, when decreasing the SOL qty, an unexpected picking
will be created
To reproduce the error:
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
- Outgoing: 2 steps
3. Create a storable product P
4. Update the on hand qty:
- 10 x P at WH/Stock
5. Create and confirm a SO with 10 x P
6. Process the pickings with 6 x P (with backorders)
- There should be 4 pickings
7. On the SO, decrease the quantity to 7
Error: an unexpected picking (customer -> out) is created for 3 x P
Step 6, when creating a backorder for 4 x P from out to customer,
we split the initial SM, and we force the `procure_method` to
`make_to_stock`
Step 7, when decreasing the qty, we create a negative procurement
and run the rules' system. Because of warehouse configuration, the
rule that links output location and customer one is based on an MTO
logic: the SM for -3 x P has the `procure_method` set to
`make_to_order`. As a result, that move will not be merged with the
one created during the split (step 6) and we will create the
unexpected picking for the move.
The SM generated by the split should keep the same procure method
logic as the initial one.
OPW-3141387
closesodoo/odoo#114787
X-original-commit: 920924e963d389ab2f962e0fe45ef229641d00c4
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
We forget to remove few 'props.value' in 688986f888.
We should replace it by 'props.record.data[props.name]'.
closesodoo/odoo#114785
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
pos_*: pos_adyen, pos_six
The use of the Markup was meant to keep the formatting (mostly the line breaks) of the data
given by the payment terminals. The data was stored on the `ticket` attribute of the `Payment`
model. A security issue arose from the fact that it is possible to import orders from a file
via the debug widget.
The `ticket` attribute was initialized in the `init_from_json` method and could be injected
with some malicious code.
Solution:
Instead of replacing all line breaks by the `<br/>` tag whenever terminal data is retrieved,
we can simply store this as it is in the `ticket` attribute. We then escape the value before
replacing the line breaks when exporting the data as a Markup. With this, only our `<br/>` tags
are trusted.
closesodoo/odoo#114770
X-original-commit: 7194506648c3512dc6a80d4a92a986643e60c5d2
Related: odoo/enterprise#37962
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
- Create an Order, send to customer
- Create an invoice from this sale
--> Issue the customer can show the invoice in draft mode
This prevent customer to print a draft invoice with wrong value.
Only show send invoice.
closesodoo/odoo#114765
X-original-commit: 687f479297fcaa047cd26a34883e7de11b3d3dea
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
When we create a new record X and its values contains an one2many field
with either a recordset Y or a Command.set(ids), the ORM generates extra
SQL queries to search and remove the existing lines of the new record.
The call chain is as follows:
Model._create
-> _RelationalMulti.create
-> _RelationalMulti.write_batch
-> One2many.write_real
But because record X is brand new, it has no lines to begin with. The
fix consists in skipping the search and removal in that case.
Also remove any nondeterministic behavior of method write_real() using
an OrderedSet instead of a builtin set.
closesodoo/odoo#114726
X-original-commit: 428827e5213ee002a5b50d864f8ce1f24d1842b3
Signed-off-by: Raphael Collet <rco@odoo.com>
Some modals (`.o_error_dialog`) have a visual bug and goes outside the
viewport. This bug occurs because the CSS `top` attribute is override by
an inline style.
The result CSS is
```css
.o_error_dialog {
top: 50%; /* Ignored due to the inline top rule */
transform: translateY(-50%);
top: 0; /* Override inline style */
}
```
The commit instead use the Bootstrap 5.1 class `modal-dialog-centered`
to center vertically the modal.
Note: from now all modal will be center vertically as it's the direction
of the future design.
Steps to reproduce:
* Go to `Bank Accounts` menu
* Create a new recode (New button)
* Enter a `Account Number` and select an `Account Holder`
* Then check `Send Money`
* Try to save (cloud icon) => BUG the modal is outside the viewport
closesodoo/odoo#114535
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This PR change the delete button in the attendee calendar if the
event is recurrent.
If the event is recurrent, a wizard pop up to ask if you
wish to remove :
- The selected event
- The selected event and the following
- All the event in the recurrence
task-id : 3148011
closesodoo/odoo#113024
Signed-off-by: Arnaud Joset <arj@odoo.com>
The logic to display the payment status of invoice(s) has been quite
messy for a long time, leading to a lot of confusion and some bugfixes.
This commit tries to simplify and harmonize the logic, and to provide
a clear logic and ordering of the payment states, following
1) the invoice state (cancelled state)
2) the accounting state (related to `account.payment` records and logic)
3) the payment state (related to `payment.transaction` records, holding
states not reflected in accounting logic until effectively confirmed).
closesodoo/odoo#111046
Related: odoo/upgrade#4409
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The module ´account_payment_invoice_online_payment_patch´ was added in stable to allow
account_payment users to disable online invoice payment
(without removing the module, critical for other flows).
It can be safely merged into the account_payment module for future versions.
Original bugfix PR: #110177
Related to opw-3114860
Part-of: odoo/odoo#111046
CONTEXT
Followup of odoo/odoo@2d791e8afe (posting, notifying and composer / template link code
cleaning) and odoo/odoo@0b8d4c0eb1 (composer fields, template sync and values generation
cleaning).
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template on the composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered on composer side.
As composer is not translated -> no translation -> ko;
Email layout situation when posting / mailing
* comment, monorecord model, using a template from UX: layout is partly
translated based on template 'lang' field to match the content translation.
Part of the layout still uses the current user lang;
* other comment use cases: layout is translated based on current user;
* mailing mode: layout not supported;
EXPECTED SITUATION
Content situation when using a template to post on a composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered and translated if
matching template content -> ok;
Email layout situation when posting / mailing
* comment: layout translated based on recipient lang or fallback on template
'lang' field definition, or current user's lang;
* mailing: support layout through composer, use template 'lang' field definition
or fallback on current user's lang;
For more details, see sub commits with their detailed explanations.
LINKS
Task-3046371 (Mail: Better Language Support in Composer)
Task-2742033 (Mail: Use recipient lang in template contextual action)
Task-2555155 (Mail: Translate notification action/access buttons)
Task-3186426 (Mail: Support notification layout in template / email composer)
closesodoo/odoo#106177
Related: odoo/enterprise#37296
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template to post on a composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered and translated if
matching template content -> ok;
Email layout situation when posting / mailing
* comment: layout translated based on recipient lang or fallback on template
'lang' field definition, or current user's lang;
* mailing: no layout supported;
PURPOSE
Make those the two composer modes less different by supporting layouting in
mailing mode of composer. Consider it a bit experimental.
SPECIFICATIONS
When using the composer in mailing mode, render email layout if given. This
layout is used to encapsulate body.
To simplify rendering and sending, consider all recipients to be 'customer'
as defined in '_notify_get_recipients'. This means all recipients receive the
same basic layouting currently as a first attempt to improve this situation.
Considered lang is the one coming from the template 'lang' field, or fallback
on current user's lang.
Task-3186426 (Mail: Support notification layout in template / email composer)
Part-of: odoo/odoo#106177
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template to post on a composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered and translated if
matching template content -> ok;
Email layout situation when posting / mailing
* comment: layout translated based on template 'lang' field definition
or fallback on current user's lang;
* mailing: no layout supported;
PURPOSE
Translate layout into recipient's lang when available, instead of either
current user or template defined lang. As it is contextual better translate
it to the end user lang.
SPECIFICATIONS
Move recipients and email layout rendering into a method returning an iterator.
That way a list of recipient groups (as given by '_notify_get_recipients') can
be split into sub-groups, with each having its own rendering values for
email notifications.
Do a split / recipient lang. It is already fetched when notifying messages
as part of '_get_recipient_data' returned values. We now return recipients
groups per lang and per usage type (user, portal, customer, ...). Rendering
values are computed for each group as several values depend on the lang (
actions, notification buttons, global layout, ...).
Layouts when posting are dependent on recipient lang, and not on current user
anymore. Template lang that forced the content lang is now used only as a
fallback when recipient have no lang.
SUMMARY
When a user in Spanish, posts using a template specifying the lang of the
customer on a record whose customer is in French, with a follower being
in English
* content will be translated following template choice, aka french;
* layouting for the french customer will be in french, layouting for the
english customer is in english, while the core content is always the
same and in french;
When a user in Spanish, posts some custome content on a record whose customer
is in French, with a follower being in English
* content is whatever the user wrote;
* layouting for the french customer will be in french, layouting for the
english customer is in english, while the core content is always the
same and in french;
Task-3046371 (Mail: Better Language Support in Composer)
Task-2555155 (Mail: Translate notification action/access buttons)
Task-3186426 (Mail: Support notification layout in template / email composer)
Part-of: odoo/odoo#106177
Co-authored-by: Julien Banken <jbn@odoo.com>
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template to post on a composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered and translated if
matching template content -> ok;
Email layout situation when posting / mailing
* comment, monorecord model, using a template from UX: layout is partly
translated based on template 'lang' field to match the content translation.
Part of the layout still uses the current user lang;
* other comment use cases: layout is translated based on current user lang;
* mailing mode: layout not supported;
PURPOSE
Correctly propagate lang from template in all situations whenever a template
is used, and translate all layout parts.
SPECIFICATIONS
When using the composer to post messages (either as comment or in batch) the
language coming from the template is not propagated until the notification
process.
A hack has been done to try to guess the language inside the notification
process, based on context keys at odoo/odoo@9e71d228ed. This was done to partly fix
the bug in stable.
Since odoo/odoo@3eb9680602 it is possible to propagate a lang from 'message_post' or
'message_notify' calls until the notification process. We can therefore call
the posting methods using the rendered lang (in both mono and multi record
modes) and remove that hack.
When a lang is propagated using the 'force_email_lang' it is used to choose
the language of the layout (content, buttons). Currently all recipients
receives the same language for layouting. We plan to soon use the recipient
language when possible, then fallback on that forced lang. This will offer
more granularity and a better user experience.
When using scheduled messages (creating message but delaying the sending of
notifications) it is also working as notification parameters are saved when
creating the scheduling record, see odoo/odoo@9b11a9d82b.
EXAMPLE
A user in english uses a template on a lead whose customer is in spanish
with a follower being in german. Template lang is customer's lang:
* content is translated into spanish (customer's lang);
* layout is translated into spanish (customer's lang);
Both recipients (customer and follower) receive the content in spanish.
LINKS
Task-3046371 (Mail: Better Language Support in Composer)
Task-2555155 (Mail: Translate notification action/access buttons)
Part-of: odoo/odoo#106177
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template on the composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered on composer side.
As composer is not translated -> no translation -> ko;
PURPOSE
Take translations from template when composer content is the same as the
template one to benefits from their translations.
SPECIFICATIONS
When rendering some fields fetching translations can be complicated. Indeed
when using a template the translation is stored on template model while the
rendering is done on composer model. Translations are therefore not fetched
as fields of the composer record itself are not translated. It is a transient
record, not something people translate manually like templates.
As translations are not stored in a table anymore we can't really fetch
translations, except from using directly the template field. In this commit
we therefore do the rendering based on template value instead of composer
value when they are considered as equal and if a translation is asked either
through 'compute_lang' of 'force_lang'. This allows to fetch template
translations instead of composer translations.
If the composer content has been modified compared to the template we keep
the old behavior, which means probably no translations. Let us hope editor
does not mess too much with html content.
EXAMPLE
A user in english uses a template on a lead whose customer is in spanish
with a follower being in german. Template lang is customer's lang:
* content is translated into spanish (customer's lang);
Concerning layout (to be fixed in next commits):
* layout is partly translated into spanish (customer's lang) if coming from
form view, otherwise is in english (current user's lang);
LINKS
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
When rendering content, options can be given to trigger some behavior
like post processing (links shortening) or comments to preserve in html
(for email reader specific commands).
In this commit we make an allowed list of options. This eases debugging
or finding wrong calls, outdated options, ...
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
Purpose of this commit is to improve behavior or mail.compose.mixin when
removing the template. It now voids the value to avoid having half baked
definition on composers.
Summary of behavior
* when choosing a template: existing (non void) values override any value
in the composer mixin;
* when removing a template: reset values;
* when going from templateA to templateB: works like choosing a template
which means only non void values are taken. This may lead to half-baked
content but trying to remove old template content based on _origin and
content comparisons would be complicated for few added value;
This makes the 'mail.compose.mixin' behaves like 'mail.compose.message'
wizard which was recently updated at odoo/odoo#107356.
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#106177
yhu-odoo