PURPOSE
Improve mail rendering tools and prepare ground for QWeb rendering.
SPECIFICATIONS: MODEL FOR RENDERING
Currently ``mail.render.mixin`` offers rendering tools, some of them being
based on a ``model`` field. It allows to know which model to use to fetch
records on which we perform rendering. However this field is not defined at
mixin level but in inheriting models without being clearly implemented that
way (see ``mail.template`` or ``sms.template`` models).
In order to clean this mixin it is now defined at mixin level, using a
not stored computed field allowing to define how to find this model. Sub
models are updated accordingly.
SPECIFICATIONS: COMPOSER MIXIN
This merge introduces a new mixin ``mail.composer.mixin`` used when sending
emails or notifications based on a mail template.
Main current purpose is to hide details related to subject and body computation
and rendering based on a mail.template. It also give the base tools to control
who is allowed to edit body, notably when dealing with templating language
like jinja or qweb.
It is meant to evolve in a near future with upcoming support of qweb and fine
grain control of rendering access.
Use it in survey and slides invite wizards, as well as appraisal and appraisal
survey (in enterprise). Use it in mail composer in a minimal way.
SPECIFICATIONS: QWeb
Temporarily and experimentally support Qweb rendering even if not used
functionally, to prepare QWeb templates.
LINKS
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
UPG PR odoo/upgrade#2490
Related: odoo/upgrade#2496
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to prepare ground for future improvements by already
supporting QWeb rendering in ``mail.render.mixin``.
We temporarily support new field parameters allowing to tune the rendering
directly from field. Notaby choosing engine (jinja or qweb) can be done
from field directly. This is considered as experimental, used mainly to
prepare QWeb support.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
Prepares Task ID-27033 (QWeb in templates)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Purpose is to have all mail template into a mail_template_data.xml file
when possible. It eases maintenance and update when having to work globally
on template records.
Also update some ``body_html`` declarations still using ``xml`` instead of
``html``.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
Prepares Task ID-27033 (QWeb in templates)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Using this mixin allows to hide details about jinja-based computation for
main fields used when posting messages or sending emails. Notably subject
and body computation that was duplicated in several addons are now done
in a mixin. It also eases their maintenance or evolution when qweb rendering
will be available. It also eases support of lang when necessary.
``mail.compose.message`` is still overriding default mixin behavior to keep
a minimal fix. Rewriting composer code is planned but will not be done with
this task. Here we keep current behavior, technically and functionally.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo#70889
ENT PR odoo/enterprise#18352
UPG PR odoo/upgrade#2496
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
In this commit we fix some glitches in slide invite process
* prevent from sending without recipients as it makes no sense;
* hide Invite link in kanban like Invite button on form view, when not
being invite-based;
* fix small issues in various templates, notably escaping in subject;
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo/odoo#70889
Using this mixin allows to hide details about jinja-based computation for
main fields used when posting messages or sending emails. Notably subject
and body computation that was duplicated in several addons are now done
in a mixin. It also eases their maintenance or evolution when qweb rendering
will be available. It also eases support of lang when necessary.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
UPG PR odoo/upgrade#2496
Using this mixin allows to hide details about jinja-based computation for
main fields used when posting messages or sending emails. Notably subject
and body computation that was duplicated in several addons are now done
in a mixin. It also eases their maintenance or evolution when qweb rendering
will be available. It also eases support of lang when necessary.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
UPG PR odoo/upgrade#2496
This commits introduces a new mixin ``mail.composer.mixin`` used when sending
emails or notifications based on a mail template.
Main current purpose is to hide details related to subject and body computation
and rendering based on a mail.template. It also give the base tools to control
who is allowed to edit body, notably when dealing with templating language
like jinja or qweb.
It is meant to evolve in a near future with upcoming support of qweb and fine
grain control of rendering access.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Currently ``mail.render.mixin`` offers rendering tools, some of them being
based on a ``model`` field. It allows to know which model to use to fetch
records on which we perform rendering. However this field is not defined at
mixin level but in inheriting models without being clearly implemented that
way (see ``mail.template`` or ``sms.template`` models).
In order to clean this mixin it is now defined at mixin level, using a
not stored computed field allowing to define how to find this model. Sub
models are updated accordingly.
Other cleaning is done in the render mixin
* rename ``_render_template_qweb`` to ``_render_template_qweb_view``
to indicate it works on views, not on raw qweb templates;
* extract some common available variables for rendering in a method then
called / upated for jinja and qweb views;
* correctly set same rendering context for jinja and qweb views rendering;
* allow to propagate an additional context from _render_field to sub
rendering methods;
* allow to propagate options through rendering methods (notably for escaping
or safe attributes in jinja);
* allow to specify engine used to render lang;
* clean or update some docstrings;
Some tests are also added, as render mixin lacks some more detailed test to
ensure various use cases will be correctly migrated to other engines like
QWeb.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
Prepares Task ID-27033 (QWeb in templates)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
This commit fixes the UserError message by properly displaying the
number of maximum leads that can be merged.
Apart from that, this commit also hides 'email_from' and 'phone' fields
on merge wizard to avoid scroll and to make sure that the 'x' icon is
always visible, which previously was far right and user had to scroll
a bit for removing the lines with that button.
TaskID-2542260
closesodoo/odoo#71523
X-original-commit: abbf3419767c149f338a4a48f15c2af7dfbed2bc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Remove arbitrary write on template used in signup process. Instead of writing
on template if some values are not correct compared to the current flow
we force values given to ``send_mail``. It allows to let people tune the
template while still having a working auth signup process.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Before this commit, the className can be null and then this processing:
`this.className += ' o_clickable_m2x_avatar';` gives
'null o_clickable_m2x_avatar' in the class of the element classList.
This commit checks if the className is not null if yes, then we add the
the class otherwise the className is created in this mixins.
closesodoo/odoo#71461
X-original-commit: d25459e6cb
Related: odoo/enterprise#18605
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To make the account.account form view usability better, we'll move around the fields,
add a new smart button to link the account to the taxes using it as well as
add a chatter to keep track of changes.
Task id #2481421closesodoo/odoo#69851
Related: odoo/enterprise#17943
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the bug:
- Install Accounting
- Connect with a user who has a default company (e.g: Company A) and allowed companies (e.g: “Company A” and “Company B”)
- Choose in the company selector “Company B”
- Make sure that the onboarding panel in the default company has not been closed
- Go to accounting and close the onboarding panel
- Refresh the page
Problem:
The onboarding panel is still open because in the `account/account_dashboard_onboarding` method we check the`account_dashboard_onboarding_state` field of the default company instead of the current company because "allowed_company_ids" is not in the context
This problem is also present in all the other views where an onboarding panel is present
Solution:
Add the context in the parameters of the rpc in the _renderBanner
opw-2477148
closesodoo/odoo#71420
X-original-commit: d9b794480a5ab7f7d6a1e0d92601eb737175e212
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
On an invoice, we have the possiblity to set the bank account where
the client's payment has to be done.
If our company has two payment journal with 2 differents bank accounts
(bank A & bank B) set on each of the journal (journal A & journal B),
if I create an invoice and set bank B as bank account, after clicking
on "Register Payment", the journal A will be automatically selected.
With this PR the payment journal linked to the bank account set on the
invoice is automatically selected
closesodoo/odoo#71191
Task: 2524441
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
When using the "Send & Print" functionality, if the user adds an
attachment, the latter won't be linked to the record.
To reproduce the error:
1. Open a posted invoice
2. Send & Print
3. Attach a file > Select a file on your device
4. Send the email
Error: The invoice's PDF is added to record's attachments, but not the
other file (from step 3).
When the module selects the attachments that need to be linked to the
invoice, it only keeps the ones currently linked to `mail.compose.message`:
https://github.com/odoo/odoo/blob/6441ab71cb68648aa735057952bf757677a20ee3/addons/mail/models/mail_thread.py#L1719-L1725
This is correct when the user creates a message directly in the chatter.
However, when the mail is created thanks to `Send & Print` functionality,
the attachment is linked to `account.invoice.send`.
Another flow have a similar issue: from invoices list, select few ones,
Action > Send & Print: the generated PDF won't be attached to their
invoice. In such a situation, here is the source of the problem:
https://github.com/odoo/odoo/blob/05ad6c477f7da2a495e5baf5b4629323b9d11fa0/addons/mail/wizard/mail_compose_message.py#L363-L367
There isn't any information about the invoice, therefore it is not
possible to linked the attachment to it.
OPW-2438457
closesodoo/odoo#71495
X-original-commit: 98d3748aca724ef06db89294531d82679df45b74
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
General improvements of the new Inventory Adjustment mechanism, among which:
From the Inventory Adjustment page
- A new inventory_quantity_set Boolean field is used to hide the Counted Quantity when not set instead of showing 0.
- Possibile to set 0 as a Counted Quantity directly (not using the set button).
- Allows to provide a name for the Inventory Adjustment when using the Apply button at the top of the tree view. This name is applied on the corresponding stock moves.
- Add warnings when trying to Apply/Set on multiple records when some records are not set/already set.
- Highlight lines when there is a mismatch between Quantity / Counted Quantity / Difference. If the user still tries to Apply, shows the option to either keep the current Difference or the current Counted Quantity for all records.
- Set the user when directly inserting a Counted Quantity (before only when using the Set button)
- Add the possibility to import records.
- Add "To Apply" filter.
- Add a 'Reset' button at the top of the tree view for multiple records.
From the Update Quantity page of a product
- Remove the "Updated on Hand Quantity" and can directly change "On Hand" quantity
- Pre-fill a default location (Last used location for tracked products or default destination location in single WH environment)
From the Inventory Report
- Remove the "Updated on Hand Quantity" and can directly change "On Hand" quantity
closesodoo/odoo#71199
Task-id: 2495664
Pr-community: 71199
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When scanned product is tracked by lot or SN, the popup that asks
for lot should be shown, just like as when a tracked product is clicked
from the product list.
We accomplish this by introducing a new method that can be used both
by `_clickProduct` and `_barcodeProductAction`, and by making the
`_barcodeProductAction` be independent from `scan_product` method
from `PosModel`. So instead of calling directly `scan_product`, we
indentify the product first based on the barcode, then we call the
newly introduced method to ask for the lot inputs, then we call
`add_product` with proper options including the type of the parsed
barcode.
closesodoo/odoo#71496
X-original-commit: 4383cacefd01a318df70857cddf5aedda7011318
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When identifying whether to show the decrease quantity popup or not,
the current quantity of the selected orderline is compared to the
new input quantity. This fix properly compares the current quantity
to the new input quantity in number format.
X-original-commit: 61bb684c4b610227a3a22e68512146dc2ee5974d
Language such as FR recognizes `,` as the decimal separator. However, it is
possible that the keyboard setting is American so the decimal point in the
numpad will send `.` when pressing it. POS should be able to recognize both.
This fix allows `.` sent from keyboard to be interpreted as decimal separator
even at language where the decimal separator is `,`. This is okay because
number inputs in POS doesn't take into account the thousand separator.
X-original-commit: 444fc5621b1157fe3c442f6a1aecfd00d5f8e5d7
Like commit odoo/odoo@1c5c762f3c
On some device (like Android Mobile) where the background is printed,
the receipt (which is white) is surrounded by a black background.
This commit fixes it by matching the receipt background (cf. white)
for the whole document and avoiding to print unnecessary background colors.
opw-1940434
X-original-commit: cf1a555ca2bc474ead1ef4fc063e8210678800d9
The "Add image" button was shown out of the editor mode when removing
all images from a snippet.
task-2469516
closesodoo/odoo#71486
X-original-commit: 3bae864d1e587e87262c56f1c5f789ac6a6fabc4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
A FEC file (Fichier des Ecritures Comptables) contains all the accounting data and entries recorded
in all the accounting journals for a financial year. In order to make the onboarding of new users
easier, Odoo Enterprise's French fiscal localization includes access to the ``l10n_fr_fec_import``
module, that enables the import of existing FEC files from older software to the Odoo database.
The imported data are:
* accounts
* journals
* partners
* journal entries
Every entity is imported with a generator that reads the values from each line, ready to be loaded.
The entity (only accounts for the moment) is then completed with data from the CoA's templates
and imported in the database. Journal entries are posted and reconciled.
The Odoo branch implements the install checkbox in the Settings > Accounting page for an easy install.
Task 2515785: https://www.odoo.com/web#id=2515785model=project.task
Documentation PR: odoo/documentation#979closesodoo/odoo#71290
Related: odoo/enterprise#16704
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
When invoking onchange() on a line in a one2many field, the inverse
many2one field is given as a dict of values. Those values are the ones
of the "container" record in the form view, and they include the "id" of
the container record. The method onchange() instantiates the container
record as a new record with the given values. Fix the code to set the
expected "origin" of that record to the record with the given "id".
closesodoo/odoo#71491
X-original-commit: ebfb5d90fd4ff65ee1d2fc73faf8f9eaa18f4521
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Infinite number of records cannot be exported, so after some limit we will get a
timeout error. If you need to export more records than that limit, you should be
able to filter records into batches. The easiest way to do it is making a
filter by ID:
```
[Y| ID Greater than 100000] [Y| ID less than or equal to 200000]
```
---
opw-2517946
closesodoo/odoo#71450
X-original-commit: 96b102cce95d6ed1bb6a66c17e0d39f96b05459f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Before this commit, the ir_model_fields used in the query could be
another field than the one expected, that is the stage_id field.
Indeed, since we don't check if the name column in the ir_model_fields
is right the stage_id field then we could have the user_id or another
many2one field.
This commit adds a check to be sure we only use the stage_id.
Related PR: #68343closesodoo/odoo#71478
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Steps:
- Install sale
- Go to Settings / Translations / Languages
- Activate Dutch
- Go to Settings / Users & Companies / Users
- Edit demo
- Language: Dutch
- Go to Sales
- Create a quotation:
- Customer: demo
- Go to Settings / Technical / Automation / Scheduled Actions
- Create a new action:
- Model: Sales Order
- Python code:
```python
last_id = model.search([], order='id desc', limit=1)[0].id
env.ref('sale.email_template_edi_sale').send_mail(last_id, notif_layout='mail.mail_notification_paynow')
```
- Click "Run Manually"
- Go to Settings / Technical / Email / Emails
- Open the last email you just sent
Bug:
Parts of the email are not in Dutch
Explanation:
This commit makes a template pass the rendering language to the layout
and the display name when calling `template.send_mail()`.
opw:2467640
closesodoo/odoo#71446
X-original-commit: 74da8e27c7e16fa92eb1547cec1a7ce82e15e0c6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
On a delivery, when changing the initial demand of a stock move, if its
value was 0 and becomes > 0, its state will be 'Partially Available' but
the reserved quantity will still be 0.
To reproduce the error:
1. Create 2 products P01, P02
- Product Type: Storable
- Qty On Hand: 1
2. Create + Confirm a SO with 1xP01 and 1xP02
3. Open SO's delivery
4. Unlock, set P01's initial demand to 0, Save, Lock
5. Unreserve, Check Availability
6. Unlock, set P01's initial demand to 1, Save
7. Click on PO1 line
Error: The stock move state is "Partially Available", but the initial
demand is 1 and the reserved quantity is 0. It should be "Waiting
Availability"
On step 5, since the wanted quantity of P01 is 0, the state of the stock
move becomes "Available". Then, when increasing the requested quantity,
the state automatically becomes "Partially Available" because the module
does not consider the case where the state is "Available" with a
reserved quantity equal to 0.
OPW-2488580
closesodoo/odoo#71445
X-original-commit: 05b6dfa0b1e4daf46d569c2e0a330b35e6437f8d
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
The container size of a forum post was not correct when an image was
displayed with right or left alignment.
The css property clear was added at the end of the posts so that
floating elements do not float over the next section.
task-2469516
Part of https://github.com/odoo/odoo/pull/70235
X-original-commit: 0c58901cbef8b1d1808f673b7b34d1de93c2fd6d
The container size of a text block snippet (and every snippet without
rows) was not correct when an image was displayed with right or left
alignment.
The css property clear was added at the end of the containers so that
floating elements from the section do not float over the next section.
task-2469516
closesodoo/odoo#71438
X-original-commit: fb556ed09c7ed00afbed33b6029b1315a113575a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* `hasclass` should be used instead of `@class`
* fields added to a template should be present in `base.document.layout`
in order to be able to display the preview.
closesodoo/odoo#71249
Signed-off-by: Josse Colpaert <jco@openerp.com>
Purpose
=======
This commit allow the users to translate their Gmail Addon.
The language of the addon will be the language the user set on his
preference, on his Odoo database.
The translations will be downloaded from Odoo and stored in the cache,
so translator can use the existing system to translate the addon.
Task 2502261
See odoo/mail-client-extensions/pull/8
See odoo/odoo/pull/69288
See odoo/enterprise/pull/17711
closesodoo/odoo#69288
Related: odoo/enterprise#17711
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When an invoice is created from pos having a cash rounding method, the
value of the rounding can depend on the payment methods.
When no rounding has been applied because of the order has been
partially paid by cash and bank, the rounding line should be deleted
from the invoice. We should also adapt the terms lines.
closesodoo/odoo#71410
X-original-commit: 846c63b6e5414d2b4620f389817379506a419573
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
To reproduce:
1. Sell an anglo product (inventory valuation = automated) in the pos app.
2. Go back to the backend, find the pos.order and invoice it.
3. Close the session.
4. Open the journal items related to the session (click the Journal Items
button in the session form).
5. You will see COGS (Expenses) Account and Stock Interim (Delivered) are
debited in two journal entries - one from the invoice and one from the
created picking after the closing of session.
This is because we are not properly skipping the invoiced order when
generating the global picking for the session. This commit fixes the
described issue.
closesodoo/odoo#71404
X-original-commit: 4320794da1129c7fffdebd9d0469dd81dd1f212b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
By explaining why a payment was refused or had an error,
we can understand easily what has to be done to get the payment done,
instead of just knowing it was refused/had an error.
task-2501723
closesodoo/odoo#69929
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit simply makes the mail.template name field translatable.
It had not been done yet since the model is quite technical but it's still
displayed for the end users within the composer so it's better to have it
translated if need be.
Task-2543495
closesodoo/odoo#71408
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some flows of the core `sale` code (sale_order & sale_order_line)
weren't covered at all by tests.
This commit adds some tests to cover those flows, reducing the risks of
broken features/flows with future sale tasks.
closesodoo/odoo#71402
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
stdout:
stderr:
17:49:30.703303 git.c:344 trace: built-in: git cherry-pick 3c8bdde81d508fdee301f13bcbc6e4eefc9fb02c
error: Cherry-picking is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: cherry-pick failed
----------
status:
closesodoo/odoo#71390
X-original-commit: 7033f4aa7d1c65ad13dcd19e66378b101b56238b
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Because the `receiptHtml` was taken from a component which was mounted outside of the DOM, it was hardly ever destroyed for some unknown reasons and the `el.outerHTML` could not be taken to create the receipt.
closesodoo/odoo#71399
X-original-commit: a54d54c9c479aaee3bafe6e241d89d557a1e0b56
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When trying to filter links by a tracked URL code, the following warning
is shown:
WARNING dbname odoo.models: Cannot execute name_search, no _rec_name
defined on link.tracker.code
and the applied filter gives all records.
closesodoo/odoo#71398
X-original-commit: 3687dabbc373e57e24ca4596c18ef1dacfde8273
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
The default tree view action (debug mode) of account.move.line currently hides lines in the cancelled state. This commit modifies the default domain on the action.
Users can now filter and group all lines
part 3 of task (2486685)[https://www.odoo.com/web#id=2486685&model=project.task]
closesodoo/odoo#71392
Signed-off-by: William André (wan) <wan@odoo.com>
jbw