Purpose
=======
The fields are not used, don't work correctly and there is a specific
report to generate the product prices according to the pricelist and
the ordered quantities
Cache the pricelist rule used for price computation in a dedicated non
stored field, since it is used both for the price_unit and the discount
computation.
This divides by 2 the number of pricelist requests/queries when
discounts computation is enabled.
* Leave the flush to the orm
* Ease inheritance and customizations
* Make sure the order is correctly shared with the
product.pricelist.item model order
* Do not rely on context, everything should be cleary specified through
parameters
Catch context keys in an unique targeted place to improve code clarity
* Drop strange old API
* do not provide unused partner parameter anymore
* do not provide products, qty as a list of tuple, we only request the
same qty for all products anyway
* Clear methods, add/adapt comments and docstrings
* Reduce potential side-effects of context content.
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>
Yannick Tivisse