Steps to repoduce:
- Accounting > Customers > Invoices:
select several invoices to send
- Action > Send & Print > (deselect Print) > Send & Print
Issue:
- It sends only one invoice per company
Cause:
- the mail_compose_message sets the status of an email as `cancel` when a mail has already been sent to a specific adress mail in the batch
Solution:
- If the use of mass mailing is document-based (e.g.: sending multiple invoices) it will allow to send multiple emails to the same adress
opw-2775121
closesodoo/odoo#88992
X-original-commit: f08685020f6a00d4e10e30ccbcf70c9eb1a764d5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Most of the extensions of `_name_get` are very similar and only want to
search for the given string in multiple fields.
A lot of extensions also don't take into account the negative operators.
Some implementations were also really outdated and needlessly
complicated.
closesodoo/odoo#86588
Related: odoo/enterprise#25608
Signed-off-by: Raphael Collet <rco@odoo.com>
Add a reception/delivery status on sale orders and purchase orders.
The idea is to have an indication in list view about the situation
of pickings linked to the SO/PO.
Inside the document itself, the quantity delivered decoration are
designed to indicate if everything is correctly deliver or if
it still something to do. (red if the delivery/receipt is late and
incomplete)
Task-2381757
closesodoo/odoo#63356
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Unify taxes computation between 'account', 'sale' and 'purchase' including:
- computation of price_subtotal/price_total.
- computation of business models total (using the json field)
closesodoo/odoo#80231
Task: 2654784
Related: odoo/enterprise#25620
Signed-off-by: Olivier Colson <oco@odoo.com>
Improve the design of SO/PO/INV mails together with the other changes of the
release, i.e. fixes a few imprecisions introduced by odoo/odoo#82167.
In particular, these changes enforce
* a responsive, mobile friendly layout tested on many devices and OS
* more generally, a consistent styling. Note that some redundancy in directives
is required for compatibility across email clients.
Translation files are included.
Task-2751139
Follow-up of Task-2712450
See odoo/enterprise#25154closesodoo/odoo#86494
X-original-commit: 4914127b428802d2ff2e15351238a3ffef24b9cc
Related: odoo/enterprise#25306
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
How to reproduce the bug ?
- install the accounting, contacts and purchase apps
- create several companies and enable the checkboxes of all
these companies
- create a new contact and add a bank account for each company
- switch to a company different than the first one
- create a request for quotations in the purchase apps and
confirm it
- in the accounting app, create a new vendor bill and use the
auto-complete field to select the RFQ created earlier.
The bug:
When you try to create a vendor bill from a request for quotations,
the recipient bank is wrongly chosen. Because of that, there will be
2 issues. The first one is when you want to create the bill from the
RFQ: you will get an error and the invoice won't be created. The second
one is when you create an invoice then use the auto-complete field. In
this case, there won't be any error but the recipient bank will
be wrong.
opw-2731264
closesodoo/odoo#86078
X-original-commit: 074fee2e19547f4145ae0aa93d68741ab4aa9bae
Signed-off-by: Adrien Minet <admi@odoo.com>
Signed-off-by: Minet Adrien (admi) <admi@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
1. Create a PO from Indian vendor [DEMO], confirm it, receive the products.
2. Go to Accounting app, manually create the vendor bill:
- select the Vendor [DEMO]
- in auto-complete field select the one created at 1.
Traceback will raise because the field l10n_in_company_country_code
was removed from account.move in
17610e8ca9
opw-2745052
closesodoo/odoo#85501
X-original-commit: ffbfdde4b5b4cd791e866341a31cdf5e8aeb27e3
Signed-off-by: William André (wan) <wan@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
Purpose
=======
Several actions are done even if nothing has changed on the configuration.
Example:
Writing on a cron the same value makes a dummy write-lock on the table
...
Part-of: odoo/odoo#82999
PURPOSE
Allow to somehow decorate notification emails headers with a subtitle holding
the record name and some main informations.
SPECIFICATIONS
Next to access button in "Pay Now" notification email, display a subtitle
for some of the main "Send by email" based email flows. It should be something
like 'Invoice REF/01 \n35€ due 11/2022' for account.move or equivalent for
sale.order models.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
* = sale, purchase
PURPOSE
Purpose of this commit is to improve the 'Pay Now' notification template
used notably when using the "Send by email" button on
* invoices
* sale orders
* RFQ and purchase orders
SPECIFICATIONS
Global specifications
* remove gray background that is around the white content (aka have an
email with an uniform white background);
* move button on top of email like other notification templates (top-left
and company logo is top-right);
* fix various small wording issues;
* fix signature usage;
Technical specifications
Remove custom definition of access links and labels in 'Pay Now' notification
template (``mail_notification_paynow``). It is now done at model level through
the ``_notify_get_groups`` that is generic to notification emails. This allows
to remove QWeb override in purchase and sale notably. Displaying access links
is now controller by the ``has_button_access`` value. Model computes links,
access and labels while view only displays what is requested. That way any
template can use those values instead of being defined in a template subject
to user changes.
Sale / Purchase
Overrides of those modules is not necessary anymore since button labelling
and URLs are managed at model level.
Purchase "specific" buttons for Accept / Update dates are now email layout
actions, like used in other modules like HR or Project.
Continuation of odoo/odoo#76418 .
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
Purpose is to better isolate MailThread related methods in those huge files
containing lot of code. Better have them located in a sub-section in order
to have all mail code at the same place.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Having portal inherit added after mail thread prevent from really entering
portal overrides of mail.thread methods due to Odoo LRU implementation of
inherit. Notably group computation for email is not called in portal. This
means notably access tokens are not always available in notification emails.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82627
Suppose a product with several suppliers, all with the same partner. On
the purchase order, the product description will always be based on the
last supplier
To reproduce the issue:
1. Create a vendor V
2. Create a product P:
- Type: Storable
- In Purchase, add a line L01:
- Vendor: V
- Vendor Product Name: Name01
- Vendor Product Code: C01
- Quantity: 1
- Price: 10
- In Purchase, add a second line L02:
- Vendor: V
- Vendor Product Name: Name02
- Vendor Product Code: C02
- Quantity: 20
- Price: 2
- Once P is saved, ensure the lines order in the purchase tab:
- L01
- L02
3. Add a reordering rule on P:
- Min: 1
4. Run the scheduler
5. Open the generated PO
Error: The description is incorrect ("[C02] Name02" instead of "[C01]
Name01")
When computing the display name of the product,
https://github.com/odoo/odoo/blob/7691567286869ca65e63fc79c2cee11e1f415fcb/odoo/models.py#L1728-L1730
`name_get` returns a tuples list: `[(37, '[C01] Name01'), (37, '[C02]
Name02')]` where `37` is the product identifier. This list is then
converted into a dictionary and here is the issue: it will use the last
tuple to define the value for key `37`, i.e. "[C02] Name02". Therefore,
`name_get` should return the correct name, and only this one.
Another issue could be highlighted: when the user changes the quantity
of the purchase order line, if another supplier info is selected, the
description won't be updated (for the same reason as above)
OPW-2702616
closesodoo/odoo#82321
X-original-commit: a42608214f2e9ef3f5e59b4b54cd7f72a6019e06
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@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>
Editable computed fields need to have their own compute
method.
Otherwise, when providing one of the two fields at create/write time
will not be taken into account because the compute method will be
triggered for the other field.
closesodoo/odoo#77912
X-original-commit: e35dc4c87821bbb668657eed99bb51c1f853c208
Related: odoo/enterprise#21685
Signed-off-by: William André (wan) <wan@odoo.com>
RATIONALE
Currently we can specify email used for notification layouting through context
use in mail composer. It is then propagated to message_post, stored on
mail.message and used to encapsulate emails sent based on posted messages.
SPECIFICATIONS
On template model: rename ``notif_layout`` parameter of ``send_mail`` to
``email_layout_xmlid`` to be coherent with naming used in other parts of the
code. Moreover it better indicates we expect an xml id.
On rating model: rename ``notif_layout`` parameter of ``rating_send_request``
to ``email_layout_xmlid``, for the same reasons as above.
In various wizards: support ``email_layout_xmlid`` context key when no field
is available, notably because this is still done manually in some wizards
like survey invite. Keep a fallback on ``notif_layout`` but remove support of
``custom_layout`` deprecated since quite a long time.
Task-2621326 (Mail: add 'view' button in 'light notification template')
Task-2647302 (Mail: add layout field in composer)
Part-of: odoo/odoo#76418
RATIONALE
Currently we can specify email used for notification layouting through context
use in mail composer. It is then propagated to message_post, stored on
mail.message and used to encapsulate emails sent based on posted messages.
SPECIFICATIONS
Get rid of context usage (``custom_layout``) and use a real field on composer
model: ``email_layout_xmlid``. Use now a default value coming from context
(default_email_layout_xmlid) instead of custom_layout.
Support old context key in composer for backward compatibility, working like
a default value for the field itself.
Task-2621326 (Mail: add 'view' button in 'light notification template')
Task-2647302 (Mail: add layout field in composer)
UPG odoo/upgrade#2829
Part-of: odoo/odoo#76418
No longer converts the date_planned of a purchase_order_line to the
middle of the day. In case of multi-steps receipts, this caused a
discrepancy between the actual receipt and the later internal transfers.
Let's say a reordering rule is triggered :
- The date is set to midnight for the procurement, so the internal
transfer's date is set to midnight as well.
- The date is increased to noon for the PO line, which define the PO
planned_date, which define the linked receipt picking.
- So in the end :
- Receipt is planned to day X at noon.
- Transfer from Input -> Stock is planned to day X at midnight.
Task-2656397
closesodoo/odoo#79523
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Sometimes it's difficult to track the price of a product, with the
different discounts you can obtain.
Price of products might change often and it's very practical to track
the price at the moment of the order to verify that it's in line with
what you paid in the past.
Also hides the Forecast Report button when a new line is created (and
not yet saved) as the button is disabled anyway without any feedback).
New purchase history button will also hide at creation.
Task-2658786
closesodoo/odoo#78438
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before, when a foreign VAT fiscal position was used on a purchase order or sale order, no filtering was applied on the available taxes. We now make their behavior consistent with the invoices'.
Part-of: odoo/odoo#79144
Steps to reproduce:
* Create PO
* Confirm Receipt Date
* Cancel PO
* Draft and Confirm again
Current behavior:
* Button for Confirm Receipt Date is not visible
Expected behavior:
* Button for Confirm Receipt Date should be visible
This is happening as we are not resetting the value of `mail_reminder_confirmed` on cancelling PO.
With this commit, we reset value of `mail_reminder_confirmed` so use can Confirm Receipt Date again.
closesodoo/odoo#79122
X-original-commit: 9e48afe5bf4f52b7cc2705fe434b4647df752a59
Signed-off-by: Arnold Moyaux <arm@odoo.com>
It seems that this long dereference causes a MemoryError for accounts
with many associated line_ids
```
select count(*) from account_analytic_account a join account_analytic_line l on l.account_id = a.id join account_move_line ml on ml.id = l.move_id where a.id=7
+---------+
| count |
|---------|
| 131672 |
+---------+
```
The solution we propose is to use search_read inverting the order of
dereferences.
Shortened Traceback:
```
Traceback (most recent call last):
...
File "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
getattr(self, field.compute)()
File "/home/odoo/src/odoo/15.0/addons/purchase/models/analytic_account.py", line 15, in _compute_purchase_order_count
account.purchase_order_count = len(account.line_ids.move_id.purchase_order_id)
...
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 893, in update
field_cache.update(zip(records._ids, values))
MemoryError
```
Observed during the upgrade of 41031
We can reproduce this pref issue locally.
On the menu Accounting > Configuration > Analytic Accounting > Analytic Accounts, with 1 million account moves
```
test_15.0=> select account_id,count(*) from account_analytic_line group by account_id
+--------------+---------+
| account_id | count |
|--------------+---------|
| 1 | 1000002 |
+--------------+---------+
```
We get (shortened):
```
2021-10-19 07:39:33,807 53565 INFO test_15.0 werkzeug: 127.0.0.1 - - [19/Oct/2021 07:39:33] "POST /longpolling/poll HTTP/1.1" 200 - 9 0.077 50.063
2021-10-19 07:39:33,888 53565 INFO test_15.0 werkzeug: 127.0.0.1 - - [19/Oct/2021 07:39:33] "POST /longpolling/im_status HTTP/1.1" 200 - 4 0.038 0.044
2021-10-19 07:40:05,916 53565 WARNING test_15.0 odoo.service.server: Thread <Thread(odoo.service.http.request.140269940897536, started 140269940897536)> virtual real time limit (178/120s) reached.
2021-10-19 07:40:05,921 53565 INFO test_15.0 odoo.service.server: Dumping stacktrace of limit exceeding threads before reloading
2021-10-19 07:40:06,296 53565 INFO test_15.0 odoo.tools.misc:
File: "/usr/lib/python3.8/threading.py", line 890, in _bootstrap
...
File: "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File: "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
getattr(self, field.compute)()
File: "/home/odoo/src/odoo/15.0/addons/purchase/models/analytic_account.py", line 15, in _compute_purchase_order_count
account.purchase_order_count = len(account.line_ids.move_id.purchase_order_id)
File: "/home/odoo/src/odoo/15.0/odoo/fields.py", line 2605, in __get__
return self.mapped(records)
File: "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1176, in mapped
self.__get__(first(remaining), type(remaining))
File: "/home/odoo/src/odoo/15.0/odoo/fields.py", line 2603, in __get__
return super().__get__(records, owner)
File: "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1081, in __get__
recs = record._in_cache_without(self)
File: "/home/odoo/src/odoo/15.0/odoo/models.py", line 5901, in _in_cache_without
return self.browse(ids)
File: "/home/odoo/src/odoo/15.0/odoo/models.py", line 5149, in browse
ids = tuple(ids)
File: "/home/odoo/src/odoo/15.0/odoo/api.py", line 952, in get_missing_ids
if record_id not in field_cache:
```
closesodoo/odoo#78615
X-original-commit: 6077c9358fe650bcdc23e8d6a9432f639fca1b40
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Instead of using sort + groupby of itertools (which group only
consecutive), use only the groupby of odoo.tools which
decrease the complexity of the code and avoid unmatched keys
between sort keys and groupby keys
task-2648449
Part-of: odoo/odoo#76761
This allows to solve the following use case:
* we are in March
* a SO created during January shows currently a delivered quantity (timesheet on service or delivered goods on storable products): timesheets/pickings were done in February
* creating the accrued entry for January 31 should display accordingly an amount of 0 by default since everything was done in February
Invoices invoice_dates are also taken into account:
* day 0 : delivered 10
* day 2 : 5 invoiced
* accrued entries for 10 if accrual date = day 1, accrued entries for 5 if accrual date = day 3,
followup of task 2255642
closesodoo/odoo#75886
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
A new field on tax groups makes it now possible for this group to be displayed under a subtotal label. If not set, this defaults instead to "Untaxed Amount", keeping the traditional behavior. This is intended for withholding taxes, which can now be implemented with negative taxes and a tax group with this field set.
To do that, this commit entirely refactors the way amount_by_group worked, and replaces it with a more complete json field called tax_totals_json. It also streamlines the way taxe totals are displayed on invoices, PO and SO and makes it so that a common code is called instead of copy-pasting the same block 3 times as before.
[IMP] purchase: always display tax totals by groups on purchases orders
Before, tax totals on purchase.order's form were not shown by group, and were instead all aggregated in a single "Taxes" category. The same went for the pdf export. The portal view, though, did show the totals by group. We now display the tax groups in the same way all the time.
closesodoo/odoo#74138
Task: 2457374
Related: odoo/enterprise#19802
Related: odoo/upgrade#2670
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The raised error currently displays the internal state (e.g. 'purchase'
instead of 'Purchase Order') and therefore is not translated.
Task-2428819
Part-of: odoo/odoo#74364
In this commit some reorganization is performed within mail compose message
code. Purpose is to reorder a bit methods by main usage: onchange, CRUD,
actions, values generation with rendering and template management.
Some renaming is performed on action methods, notably send_mail that has some
impact on sub-addons. Finally we also set onchange and sub-onchange methods
private.
No functional change should be implied by this commit.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
When the Product Price precision is greater than the currency precision,
it can lead to incorrect data
To reproduce the error:
(Enable debug mode)
1. Settings > Technical > Database Structure > Decimal Accuracy, edit
Product Price:
- Digits: 3
2. Create a PO
- Add a product:
- Quantity: 12
- Unit Price: 0.001
3. Save, Confirm, Edit the PO:
- Qty Received: 12
- (Note that the total is $0.01)
4. Create a bill:
- Add the PO to the field "Auto-Complete"
Error: The unit price is $0.000 and so does the total
The rounding of the unit price should be based on the Product Price
precision, not the currency precision.
OPW-2601867
closesodoo/odoo#74813
X-original-commit: 1123856c77cce4b69059b63c2bcbb382c7f0719e
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Steps to reproduce:
- Install purchase and accounting apps
- Set the database to a language that is not English
- Create a purchase order
- Remove purchase representative from PO (otherwise, no issue)
- Action -> Create Vendor Bill
- From the vendor bill, print invoice
Issue:
The pdf is in English (country names, date labels, etc...)
Cause:
If invoice type is `in_invoice` or `in_refund`, it will use the
`invoice_user_id` language (object.invoice_user_id.sudo().lang).
In the above case, there is no invoice_user_id on invoice.
Solution:
While preparing invoice values, set invoice_user_id to
self.env.user.id if not user_id on PO.
opw-2510134
closesodoo/odoo#74671
X-original-commit: 4b7569ce641a6fb20d5df676bf0b315d9b9d485d
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Steps to Reproduce Bug:
- Create PO
- Remove default Currency
- Add a Line
Bug:
```ValueError: Expected singleton: res.currency()```
With this Commit, we are using default currency to round amount.
closesodoo/odoo#74234
X-original-commit: d9ff2e8ec7200aa15830e92e5083251c4e81dd1c
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Purpose of this commit is to avoid forcing mail_post_autofollow to True when
it is set to False. It eases inheritance and custom behavior.
Task-2612911
PR odoo/odoo#60792
When adding several PO to a bill, if they don't have the same currency,
it will lead to incorrect amounts
To reproduce the error:
1. In Settings, enable "Multi-Currencies"
2. Invoicing > Configuration > Currencies:
- EUR: Active, Current Rate = 2
- USD: Active, Current Rate = 1
3. Create a PO:
- Currency: USD
- Products:
- One product, no taxes, unit price 1000
4. Confirm PO
5. Edit PO:
- Qty Received: 1
6. Repeat 3 -> 5 with EUR instead of USD
7. Open a new Bill
8. Add the first PO to the field "Auto-Complete"
9. Add the second PO to the field "Auto-Complete"
Error: Both invoice lines are now expressed in EUR and both subtotals
are equal to 1000 even though the exchange rate isn't 1
This commit suggests not to change the currency of the account move if
the latter already has some AML. Moreover, the amounts must be converted
if they come from a PO that uses another currency
OPW-2573748
closesodoo/odoo#73483
X-original-commit: b299e880417026688b2fbde23307bd011de8c44d
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Issue:
For purchase user, which doesn't have the "Contact Creation" can't
create a purchase, get a AccessError.
The fields `receipt_reminder_email` and `reminder_date_before_receipt`
should be writable also for purchase user which doesn't have access
to write and create `res.partner`.
closeodoo/odoo#64135closesodoo/odoo#73131
X-original-commit: f29b1e81e6adf8532ecf90f9ecb675ec56eb4c61
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Since _filter_included_tax_company filters the taxes of other companies,
there is no need to give taxes from other companies if the filtering was
already done.
closesodoo/odoo#71591
Related: odoo/enterprise#18670
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Carlos Dauden