When an event is created from an external calendar account such as
Google or Outlook, attendee info such as email and state may be given,
and should be taken into account.
For example, if the current user who is syncing his calendar is not
the organizer of the event, his attendee state should be set to
'needsAction' and not automatically set to 'accepted'.
opw-2489815
closesodoo/odoo#81636
X-original-commit: eb1adbd6af4b01a8b3b5b16dbf2d6c32eec852e6
Signed-off-by: Arnaud Joset <arj@odoo.com>
Current behavior :
When using cash rouding method "HALF-UP" if the difference between the rounded price and the original price was exactly the half of the cash rounding, the order would appear as unpaid.
Steps to reproduce :
- Create a rounding method of 0.5 (half-up)
- Sell a product for 11.25
- The order appears unpaid in the PoS orders list view
opw-2593687
closesodoo/odoo#81830
X-original-commit: 3c452f9f731490ce94331f40ffdbe1957052000e
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Mass produce originally prohibited multiple lots components.
Later commit removed this limitation (among others).
This one displays a warning to make sure it is intentional.
task 2633369
closesodoo/odoo#77254
Related: odoo/enterprise#22797
Signed-off-by: Arnold Moyaux <arm@odoo.com>
There is 2 major issues with the production of multiple serials number
- Performance issue
- Duplicated code with classic backorder mechanism
The performance issues exist since backorders were create one by one
and `stock.move` and `stock.move.line` are always recomputed. They
are not created in batch neither.
_generate_backorders is removed and replace by _split_productions. The
functionality are the same. Technicaly it does the maximum in batch,
first it creates all the `mrp.production` then all the `stock.move`
and finaly, it splits the existing `stock.move.line` among the new
`stock.move`
It means that the reservation is not recompute anymore during a
backorder process and will remain the same than the splitted production
order.
Performance metrics (10 components):
| 2 | 10 100 1000
before | 0.47s | 2.84s | 32.25s | 580.53s
-----------------------------------------------
after | 0.13s | 0.36s | 2.60s | 35.17s
task 2633369
Part-of: odoo/odoo#77254
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>
Victor Feyens