When the system broadcasts an email response to document followers,
if the config parameters `mail.force.smtp.from` or
`mail.dynamic.smtp.from` are defined, it will rewrite the `From`
address to avoid spoofing the sender's domain.
**NOTE**: As of 15.0, this is based on the `from_filter` setting on the
corresponding ir.mail_server, rather than the abovementioned config
parameters, but the rest of the discussion stands.
For example, if the `mail.catchall.domain` is set to `example.com` and
an email response comes from:
"John D" <john@doe.com>
it will rewrite it to:
"John D (john@doe.com)" <notifications@example.com>
This will make sure the system never sends outgoing email for an external
domain, as it has no authority for doing so, and that could
break mail filtering/authentication rules (SPF, DMARC, etc.)
During this "encapsulation rewrite step", both the original Sender name
and their email are preserved, and put into the quoted "name" field of
the rewritten address. It seems sensible to preserve as much information
as possible about the original sender.
Unfortunately, the inclusion of the Sender email in the final name makes
it appear to some inbox providers as if the message is trying to
deceptively impersonate another person (as many phishing schemes would).
As of November 2021 GMail at least does this, and will hide the name in
the UI when it happens. It will keep only the rewritten email, which is not
very useful in the case of a notification (even though it's more
technically correct, of course).
This patch removes the original email from the rewritten notification,
keeping only the name, considering that the email is not the most
important part, and it's better to have one of the two than none.
So after the patch, the rewritten address is now:
"John D" <notifications@example.com>
When there is no name in the original address, we keep only the local
part of the email, to avoid the same display issue. The recipient will
have to identify the sender based on the context / past messages.
closesodoo/odoo#81807
X-original-commit: 3c65ec5a8191a392980ceb0a8c584767eae405f1
Signed-off-by: Olivier Dony <odo@odoo.com>
Before this commit, the ripple effect did not work when a button was not
in the same location/size when clicked compared to its position/size
when the page was loaded. (e.g. after scrolling the page)
task-2686370
closesodoo/odoo#81756
X-original-commit: 95728886ef3abd4e5809a5749c803c312b9267b8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
If some attendees of an event have an empty or invalid email address,
the organizer of this event should be informed that these attendees
won't receive any email notifications.
opw-2667016
closesodoo/odoo#79368
Signed-off-by: Arnaud Joset <arj@odoo.com>
Issues
------
In the module sale, with the automatic invoicing configured.
Payment transaction generate, post and send the invoice when
they are post process.
In some country the invoice is not directly ready to be sent
due to some edi document
Solution
--------
use the mechanism introduce with https://github.com/odoo/odoo/commit/3a29371eb70309f46e3b8938434287fefc23b351
to delay the sending. Introduce a cron that check invoice to send
closesodoo/odoo#81526
X-original-commit: 97b74d8304337d901d9422418cbd0dcdcc46fcf5
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this PR, user could edit notifications message.
task-2713602
closesodoo/odoo#81803
X-original-commit: 45e9f367d583ec8fafdf19c9e5451bdff0e16e62
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When clicking on save, the saved HTML should be what the user currently
sees. Before this commit, there might be cases where clicking on save
actually triggers a DOM update which occurs too late for the change to
be considered for the save. In 15.0, this manifests for example with
the blog cover saving*: if the color is being changed with the
colorpicker and that the user does not close the colorpicker before
saving, the color change is not considered because the previewMode=false
update of the colorpicker is not received. With this commit, we ensure
that DOM updates which occur because of the click on the save button
are considered before saving.
* That bug is however due to two other issues which are being fixed with
the PR at [1].
[1]: https://github.com/odoo/odoo/pull/79028closesodoo/odoo#81762
X-original-commit: 508332963202090bace0a3c877574132063c29a6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
If a form view contains the field 'display_name', when creating a new
record, the initial value of 'display_name' is the string "False", and
that weird value also appears in the breadcrumb instead of "New". In
order to avoid this unexpected behavior, the conversion of a value to a
display name should be False, like any other field would.
closesodoo/odoo#81788
Signed-off-by: Raphael Collet <rco@odoo.com>
Scale up game has been printed with the quantity show by default on the
supplier info. So we copy that behavior in standard for educational
purpose and avoid to print again all the scale up.
Also it's better from a usablity point of view since it's an important
information.
opw-fp
closesodoo/odoo#81774
X-original-commit: 4a47727c68a9f5c66ad9d7656f499b4e760f315c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
A bug[0] was detected in the Odoo Docker image 15.0 when trying to print
invoices with arabic fonts (and probably other languages that need
specific font) . It appears that the necessary fonts are not available
in the container image.
Strangely, the issue did not exists in previous Odoo Docker images.
It appears that `fonts-dejavu-core` package was installed incidentally
by `wkhtmltox`[1] which is installed from the official website.
Note that the Debian version of `wkhtmltopdf`[2] does not provide this
dependency.
In the 15.0 Docker image, while the `wkhtmltox` is installed the same
way, the `fonts-dejavu-core` package was not installed because the
dependency of `fontconfig-config`[3] was already fulfilled by the
`python3-renderpm`[4] from Debian Bullseye.
Finally, to add more confusion, the Odoo package have an indirect
dependency on `fonts-dejavu-core` through the `python3-pydot`[5] package.
This explains why the issue was not found before.
In order to avoid all this spaghetti dependency hell, this commit adds
an explicit dependency on one of the multilingual fonts available in the
Debian packages.
[0] https://github.com/odoo/docker/issues/400
[1] https://github.com/wkhtmltopdf/wkhtmltopdf/releases/0.12.5/
[2] https://packages.debian.org/bullseye/wkhtmltopdf
[3] https://packages.debian.org/bullseye/fontconfig-config
[4] https://packages.debian.org/bullseye/python3-renderpm
[5] https://packages.debian.org/bullseye/python3-pydotclosesodoo/odoo#81742
X-original-commit: 3d6043a7356b90e5a69a5b535ec6c651d0860711
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
The PR #75475 removed the method `_compute_manager_id` without removing
the reference in the field.
closesodoo/odoo#81766
X-original-commit: a4e1477d120c336ace405421ddb860a72cfeafe1
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Added a CoA that provides accounts needed for legal reports
Added taxes (sales taxes and service sales tax, even provincial)
Reports are in enterprise
closesodoo/odoo#81775
X-original-commit: a89e0f84f534ebafd0f13dbee7a65ed5551dafb1
Related: odoo/enterprise#23054
Signed-off-by: Olivier Colson <oco@odoo.com>
Consider this example:
- Create a 42% tax, price-included, with two tax repartition lines doing +100 -100
- Create an invoice of 100€ using this tax, and look at the move lines generated
==> Only a base line of 100 and a receivable/payable line of 100 have been created; no tax line.
This is wrong, as we'd expect to see:
- 100 in payable/receivable
- 100 for the base line
- 42 for the +100 tax repartition line
- -42 for the -100 tax repartition line
The two tax lines are missing because the compute_all considers the tax as a 0% one, because of the +100 -100 stuff.
OPW 2716083
closesodoo/odoo#81771
X-original-commit: 9d24e3cf002bacb09d6e955b26124dda09c15f18
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
Purpose of this commit is to add a base module holding tests for the whole
crm ecosystem. It notably holds currently performance tests, allowing to
track future improvements and changes.
Task-2720144 (Crm performance tests)
Also linked to Task-2703285 (Event performance improvements - event_crm)
closesodoo/odoo#81717
Related: odoo/enterprise#23046
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In order to test performances let us be sure all modules are installed.
Task-2703289 (Event testing and coverage)
Preparing Task-2703285 (Event performance improvements)
Part-of: odoo/odoo#81717
Followup of odoo/odoo@034d369 . Now that followers computation is done in
batch we gain 1 query per additional record to create in a recordset. Indeed
some searches are now performed in batch instead of in loop. This allows to
gain notably 19 queries on batch of 20 records to create for example.
Task-2703289 (Event testing and coverage)
Preparing Task-2703285 (Event performance improvements)
Part-of: odoo/odoo#81717
Current behavior :
Cash in/out button is not present on mobile PoS app
Steps to reproduce :
- Go on your mobile app
- Go in PoS app
opw-2704097
closesodoo/odoo#81758
X-original-commit: cdd2475251e161e5029fc5a363e28aa8163fc490
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
The previous code resulted in only the last editor to trigger its
handler having hints, as all the others would be killed by the last one.
closesodoo/odoo#81743
Task-id: 2632841
X-original-commit: e24b039ea120597ff5438deca3c69c7a1d54cd31
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This label was defined with 'for="match_text_location_label"', even though it actually isn't met for just that field, but for the three boolean fields allowing to choose where to match on the statement line. As a consequence, in debug, it displayed the helper of that field, which was confusing for the user.
closesodoo/odoo#81730
X-original-commit: a89c6300f3b9b22fc4e18b286f2f28734e750638
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
When no partner is set on a statement line, the reconciliation models try to find candidates using the payment reference or the partner name.
This was not working well when using reconciliation models configured to match on notes and/or reference. Only the default match on label was working.
As an example, consider the following case:
1) setup an invoice-matcing reconciliation model as such:
- Partner Is Set and Matches = False
- Match Invoice/bill with = Reference
2) Create an invoice with payment reference 123, for 100€
3) Create a statement line of 100€, with reference ('ref' field, inherited from account.move) = 123, label='test', and no partner set.
4) Try to reconcile the statement line
=> not match is found
OPW 2701729
X-original-commit: 74894b0da82f5f71cd22a3c9bb405696f908ef5c
Part-of: odoo/odoo#81730
Issue
-----
When a customer sign and pay a sale order from the portal and
automatic invoicing is enabled, it generate an invoice.
Once the payment done the customer is redirected to
the sale order preview with a link to the invoice created.
To display the link to the invoice the method _portal_ensure_token() is
called and write the access token token.
In parallel, if the invoice need to send edi document, the cron job is
triggered at the posting of the invoice and thus the cron job try to
write as well on the invoice as the invoice link is displayed to the
customer
This lead to a concurrent update for the cron job that do not retry in
case of concurrent update as normal transactions do. So the edi document
is never synchronized and the invoice never sent
Solution
--------
Avoid to write on the invoice while displaying the sale order portal
view by already generating the access_token in the transaction that post
the invoice
closesodoo/odoo#81731
X-original-commit: ccf76a5b8c0671e69e8875ea476d13005dab8d72
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Context
-------
On some database, record rule may be configured in such a way
that user are able to read Purchase/Sale order
with a company_id != user.company_ids
Issue
-----
This commit https://github.com/odoo/odoo/commit/4dd150950274b1d7c3b24b7665443318f94323f6#
introduce a new field tax_country_id that require to be able to read
the fiscal.position as well.
The reading of a sale.order or purchase.order should not require the
right to read the fiscal.position for the computation of a technical
field only use during the modification.
Solution
--------
Compute tax_country_id as sudo
closesodoo/odoo#80049
X-original-commit: b329c3b18197ac6db5ffdf3cb4945a14997a1f0b
Signed-off-by: Olivier Dony <odo@odoo.com>
Signed-off-by: Thibault Francois <tfr@odoo.com>
Description of the issue/feature this PR addresses:
duplicate mandatory field in popup when save the contact record.
Current behavior before PR:
Its showing same field name twice in popup which asking invalid fields.
Desired behavior after PR is merged:
it should show 'name' field only once.
Fixes#79753closesodoo/odoo#81727
X-original-commit: eb4b49e7078f4aa90f9d652de10386da38ded2dc
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Problem 1: The context was not passed when calling the resequence function.
Problem 2: Also, the subsequent read operation did not pass the full
context, but only the context of the user, not the context of the action.
A test has been added for the basic model to check that the context is properly
given after a resequence.
closesodoo/odoo#81726
X-original-commit: 75bbec4f7fe14aa9d9c310ffcbd500bd1f70b14f
Signed-off-by: Luca Vitali <luvi@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Renamed the 'Other' account type into 'Non Trade' to enhance clarity and coherence
Changed the filtering system in the accounting search view to improve coherence with the filtering system available in the reports.
It is now possible to filter the trade/non trade accounts in the accounting views.
This change may be overriden by default selections already in place.
Renaming Receivable/Payable to Trade Receivable/Trade Payable could have turned out to be confusing for accustomed users.
They are now renamed Receivable/Payable, though the Non-Trade option is still present.
task-2669128
closesodoo/odoo#79752
Related: odoo/enterprise#21773
Related: odoo/upgrade#3004
Signed-off-by: Laurent Smet <las@odoo.com>
Prior to this commit, the _search_valid method returns all the time off types.
With this commit, only the time off types that have a valid allocation are returned
task-2711388
closesodoo/odoo#81724
X-original-commit: 20a2b29ee273c505f0279f128e8ac6c13c5be043
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, in some cases the submit button of the form snippet
never stopped loading after being clicked (e.g. redirect to an anchor in
the same page).
Now, the form and the button loading effect are reset at the same time
at the appropriate time depending on the post-send action:
- Redirect to another page: never (we leave the form values and the
button loading effect for the whole redirection duration)
- Redirect to an anchor on the same page: after the scroll animation
- Show a custom HTML message: never (this type of post-send action is
meant to hide the form after that message is shown, there is no need
to restore it to its initial state)
- "Nothing" (= small message next to send button): once the data is sent
In the last two cases, a 400ms delay was also added before showing the
message so that the send flickers less and seems more smooth. In the
last case, it also prevents to double click and double send the form.
Related to task-2172312
closesodoo/odoo#81703
X-original-commit: 42f6887bb4406d4aa636040c8325e8ecab202778
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The current user of the pos session is unable to close the session even if he is the one who opened it.
This commit allows the cashier to close the session if he is linked to the user that opened the POS session.
closesodoo/odoo#81696
Task-id: 2713876
X-original-commit: 3a27e73894e374ff30246c984ec85dc72f5e9b37
Signed-off-by: Masereel Pierre <pim@odoo.com>
It was no longer possible to favorite a product and the already
favorited products were not showing.
closesodoo/odoo#81692
Taskid: 2704569
X-original-commit: 328e0384cc2cff34fc5c4131014d94efb5747cb5
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Current registrations tests run with event_crm rules being activated. In
order to better highlight their impact (which is important) let us have
some tests skipping them.
Followup of odoo/odoo#81068
Task-2703289 (Event testing and coverage)
Preparing Task-2703285 (Event performance improvements)
closesodoo/odoo#81604
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The `_insert_followers` wasn't batch in the `create` of `mail.thread`
for no reason, which call the create of a `mail.follower` one by one.
It is inefficient for the batch records creation (import or some
flows) of a model with `_inherit = [mail.thread, ...]`.
Then batch it, to miminize the cost of `_insert_followers`:
The creation of 100 `mail.follower` takes:
- 0.107 sec if you create one by one (before)
- 0.022 sec if you create in batch (now)
Also add two tests (on model with a chatter):
- One testing the behavior of follower and subtype in case of
multi-create
- One testing the number of queries done to create 5 records.
The old SQL request count was 23, now it is 19 (-1 by create
call).
task-2711448
closesodoo/odoo#80954
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
No notifications should be received whilst in Kiosk Mode.
closesodoo/odoo#81694
Taskid: 2704624
X-original-commit: 202a5a075b90a564d37c68d2f21f9c1edd8a7caf
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Prior to this commit:
- The employee was the first one returned through a search that
was not taking the company into account.
After this commit:
- The employee will be selected according to the company.
This issue arose with b5b105ea
closesodoo/odoo#81704
X-original-commit: 246caae0e70a8af0b507ba87921783a493c86064
Related: odoo/enterprise#23010
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
In owl-2, t-on will no longer be supported on components. This commit
converts the code that used to rely on the datetime-changed event to use
a callback-prop based approach instead.
closesodoo/odoo#81199
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
IdentifyingFields and fields marked `required` must have their inverse
with `isCausal: true`. This led to having to systematically declare
inverses on the related models in order to explicitly add `isCausal:
true` to them, even when these inverses are not used for anything else.
This commit automatically adds `isCausal: true` to the inverses
generated by the framework when they are related to required fields or
identifyingFields. Thus, it is no longer necessary to declare inverses
if they are not used for anything else.
This commit also removes all the inverses that are no longer needed
thanks to this change.
closesodoo/odoo#81679
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When a user double clicks on a record in the kanban view of the form view of project a crash occurs.
This happens because there is an init which is called twice and during the second time the component created during the first click is destroyed and a DOM_updated event is still trigger which leads to a crash because in the case of project_form there is has a use of the element's dom which is then no longer available.
There is the same case in "FieldHtmlWithAction" and in "MassMailingFullWidthFormController"
The problem can be easily fixed by using on_attached_callback and on_detach_callback instead of setting a listener on DOM_updated in the init method.
opw-2685867
closesodoo/odoo#81680
X-original-commit: 8d83433d463dd3d1aef321921939962883f57d68
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
Current behavior:
When a user doesn't have any HR access right he cannot access his own profile
Steps to reproduce:
-Go to the demo user settings
-Remove all the right in the HR section
-Log into demo account
-Try to access My Profile
opw-2712593
closesodoo/odoo#81674
X-original-commit: ee932eab329043a3ddf82bb39dff458f4eb7f7ad
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Step to reproduce:
Try to print traceability report
Current Behaviour:
Traceback wrongly generated header
Behaviour after PR:
No Traceback, the header is now correctly generated
opw-2704299
closesodoo/odoo#81673
X-original-commit: 6b567326edc7bc691d87d911759ee30a24a8a1d7
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Before this commit, it was possible to drag and drop a popup inside an
oe_structure which was itself inside an other oe_structure (e.g. snippet
parallax). It didn't make sense and moreover created bugs.
After this commit, it is no longer possible to drag and drop the popup
snippet or the newsletter popup snippet in a substructure.
task-2491976
closesodoo/odoo#81669
X-original-commit: 49050c124795852ce7ad51b92958498972730dcf
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
The tags management on an employee was limited to HR Administrator,
which didn't make sense as an HR Officer could manage the tags just not
assign them to an employee.
closesodoo/odoo#81654
Taskid: 2715498
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When pressing enter at the edge of an anchor that is a child of an
unbreakable element, we inserted line breaks in the anchor itself, which
is unexpected. This inserts the anchors after/before it instead.
closesodoo/odoo#81662
X-original-commit: df6f8dd0c54c40ea7edbd3821ae068d79b1b7af7
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The snippet selection was lost on every action in mass mailing. The code
that prevents that was checking if the target of a click was the body
element but for mass mailing we needed to be a little bit more
restrictive since the editable area is not the body itself and we want
to actually prevent changing the snippet selection when the target is
the iframe target as well.
Since the mailing itself has a options, the sidebar is actually never
empty and therefore removing a snippet doesn't bring us back to the
block tab. Since therefore also ensures that we actually do.
task-2716397
X-original-commit: ecdb71bf6a566f5f6c294904e84f2132561dbb3c
Part-of: odoo/odoo#81662
Olivier Dony