The test may fail non-deterministically from intercepting an
heartbeat in the local storage. Only a document thread window fold
state change from the local storage should be intercepted.
Closes#43072
Revision on https://github.com/odoo/odoo/commit/141b34f152f36d970d4ff78abe53f563555a8e69
Having async/await as a new promise constructor is an antipattern.
The reason is that it may lead to unnoticed errors: if an inner
promise is rejected, it won't propagate the error to another promise
that will handle the error. As a result, this error becomes unnoticed
and the initial promise is pending indefinitely, which also may lead
to more bugs [1].
[1] https://stackoverflow.com/a/25569299Closes#43072
Avoid double definition of the same field with different string or
help parameters. These parameters are translatable. If one has a
different value depending of the installed module, it is not possible
to properly translate it.
This problem is similar as the menu renaming debate at
odoo/enterprise@cfd4da43eeclosesodoo/odoo#42777
Related: odoo/enterprise#7623
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
"The ordered quantity has been updated." was not translated
closesodoo/odoo#43171
X-original-commit: 00c1b5210c6bae4d4aac796b2d7afb940b7c748f
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Set the company currency in USD
- Create a pricelist in EUR
- Create a SO with the EUR pricelist
- Add a stockable product
- Click on 'Add Shipping'
- Select 'Normal Delivery Charges' which has a fixed price
The price is not updated according to the USD - EUR exchange rate.
This happens because no company is set on the delivery method, so no
conversion is performed.
We fall back on the order company, then the current environement
company.
opw-2159838
closesodoo/odoo#43167
X-original-commit: 6a6a7e6e64a7e3727a6de1ca8d35361112d99de8
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Issue
- Install CRM for example
- Add 41 leads
- Create an activity on each of them
Everything ok, load more shows up
- Add another activity on one of them
Load more doesn't shows up
Cause
The uniquify method:
https://github.com/odoo/odoo/blob/saas-12.3/odoo/models.py#L4187:#L4191
Consider the second activity as a duplicate and removes it.
So, in `web_search_read`:
`len(records) <= limit` is `True` and we ignore all
the others records
Solution
Add `force_search_count` in the context when using this action
to avoid uniquify to falsify the records length.
I added the tree view for this action too. It improves UX.
OPW-2165455
closesodoo/odoo#43149
X-original-commit: 13ec3503fbfb5d3d2b1e824059737bd866a3a9f4
Signed-off-by: Jason Van Malder <jvm-odoo@users.noreply.github.com>
Try to understand a bit this code with comments. Some unnecessary code is
removed, and some parameters are added to try to understand the various flows,
but main purpose is to understand that mighty spaghetti, not destroy it.
LINKS
Side effect of Task ID 2056759 (remove crm.partner.binding mixin)
Side effect of Task ID 2088565 (crm onchange -> compute)
Community PR #43127
Enterprise PR odoo/enterpreise#7656
Related: odoo/enterprise#7656
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Lead 2 opportunity wizard file actually holds 2 wizards. Let us split files
especially that naming is quite obfuscated.
LINKS
Side effect of Task ID 2056759 (remove crm.partner.binding mixin)
Side effect of Task ID 2088565 (crm onchange -> compute)
Community PR #43127
Enterprise PR odoo/enterprise#7656
PURPOSE
As crm will soon evolve (onchange -> compute, code improvements, addition of
new features) cleaning and improving tests is necessary to help avoid issues.
SPECIFICATIONS
In this commit we add tests for the lead 2 opportunity converters. Indeed
it is strange that such a critical wizard has so few tests. Notably the
use of single-lead / multi-lead mode is more tested, allowing to see that
code is somewhat oldish.
LINKS
Side effect of Task ID 2056759 (remove crm.partner.binding mixin)
Side effect of Task ID 2088565 (crm onchange -> compute)
Community PR #43127
Enterprise PR odoo/enterprise#7656
PURPOSE
As event will soon evolve (onchange -> compute, code improvements, addition of
new features) cleaning and improving tests is necessary to help avoid issues.
SPECIFICATIONS
Use _tz_get for tz-based selection fields from partner as it smartly order
available timezones.
Remove a strange "event.confirm" wizard that calls an unexisting method,
is not reachable and is actually completely unnecessary.
Reorganize ticket fields to ease future improvements and perform some
public -> private method cleaning.
Remove duplicated code in event_sale.
LINKS
Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656
prout
PURPOSE
As event will soon evolve (onchange -> compute, code improvements, addition of
new features) cleaning and improving tests is necessary to help avoid issues.
SPECIFICATIONS
As event model grow in complexity and features, it is easier to find its
way through the application with having registration model lying in its
own file to separate it from event-specific models (event.type, event.event).
Ticket (event_sale) and sponsor (website_event_track) models are also extracted
in their own file.
LINKS
LINKS
Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656
Currently event_count is a computed field with a shortcut in computation for
non event user. It is better to directly limit this field to the event_user
group instead.
LINKS
Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656
PURPOSE
As event will soon evolve (onchange -> compute, code improvements, addition of
new features) cleaning and improving tests is necessary to help avoid issues.
SPECIFICATIONS
Clean existing tests: lessen data / variables, try to remove unnecessary
tests or merge duplicates.
Add new tests, notably event type configuration copy onto event records
is not well tested. Event computed fields are also more tested.
Some access tests are added, more a base for future addition as only a few
use cases are covered.
LINKS
Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656
Before the merge of account.invoice with account.move, a group of taxes was
expanded on journal items and not on invoice lines. Since both are now the
same thing, we only get the group of taxes when using the 'tax_ids' field.
To correctly handle this new behavior, we need to call 'flatten_taxes_hierarchy'
every time we use the 'tax_ids' field to get the children taxes instead of the
group of taxes itself.
[FIX] account: Wrong unit price with included tax and fiscal position
Steps to reproduce the bug:
Let's consider a sale included tax T1 of 10% and a sale excluded tax T2 of 0%
Let's consider a product P with T1 and a sale price of 110€
Let's consider a fiscal position FP that mappes T1 to T2
Let's consider a customer C with FP as fiscal position
Create a customer invoice for C
Add P on the first line and T1 is replaced by T2
Bug:
The unit price of P was still 110€ instead of 100€ because the included tax was not removed from the base
price of P.
Same behavior as in 11.0 and 12.0
opw:2150564
closes odoo/odoo#43100
Co-author: simongoffin (sig@odoo.com)
Forward-port-of: #42926
Forward-port-of: #42188
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The method 'test_timesheet_delivery' tests the following use case:
Test timesheet invoicing with 'invoice on delivery' timetracked products
1. Create SO and confirm it
2. log timesheet
3. create invoice
4. log other timesheet
5. create a second invoice
6. add new SO line (delivered service)
7. And finally check the AMOUNTS
But it could happen, according to the installed modules, that the class
TestSaleTimesheet, which is directly linked to
-> TestCommonSaleTimesheetNoChart (sale_timesheet)
--> TestCommonSaleNoChart (sale)
---> AccountTestNoChartCommon (account)
----> SavepointCaseWithUserDemo (base)
-----> SavepointCase (base)
is influenced by other installed modules, that in our case, introduce
new res.currency.rate values.
In our test, on the sale.order.line 'so_line_ordered_global_project',
we use the product 'product_order_timesheet2', with a price_unit=90.
Then we call manually the onchange method:
``` python3
so_line_ordered_global_project.product_id_change()
```
As the order has a pricelist and a partner, we recompute the price
unit, in case a discount applies:
``` python3
if self.order_id.pricelist_id and self.order_id.partner_id:
vals['price_unit'] = self.env['account.tax']._fix_tax_included_price_company(self._get_display_price(product), product.taxes_id, self.tax_id, self.company_id)
self.update(vals)
```
And then , the call the _get_display_price returns an different amount
that what we expect, as
``` python3
product.with_context(pricelist=self.order_id.pricelist_id.id).price
```
will return the price converted using the related res.currency.rate
at the current date.
As we don't wish to test the conversion into another currency in this
test, we simply unlink all the currency rates, to avoid any external
influence.
closesodoo/odoo#42606
Taskid: 2166237
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If the opening entry is balanced, the auto-balance line is unlinked.
However, before unlinking we test if it is balanced, which it is not. A
solution is removing the line from the move and it will be unlinked
automatically.
closesodoo/odoo#43045
X-original-commit: 56ecc9c4c2e9dcc3e06ee0a388d439845ddeedfc
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Revision on https://github.com/odoo/odoo/commit/a55c78836f172dba1cfa6db3df0e927a9c7e6471
Before this commit, marking all messages as read from Discuss inbox
did not update the UI correctly, hence requiring a page reload.
This bug comes from a typo in the commit above, which passed a list
of mail_notification instead of message ids, so that messages were
handled as marked as read by the web client.
Task-Id 2158452
closesodoo/odoo#43109
X-original-commit: 3cc03ee3db90c310dc60fe7ea18e0e6abe741ffa
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Activate Multicurrency
Create a Journal Entry with default currency (USD)
Save
Error will trigger because of the sql constraint
'check_amount_currency_balance_sign'
The currency_id and company_currency_id are the same while they
shouldn't because company_id should be unset if it is the same as the
company_currency.
Fix to update the error message to let the user know that it's best to
keep the field empty so the company_id would not be set
opw-2169523
closesodoo/odoo#43082
X-original-commit: 6a420921818d741d48bf873e0a62a220c135fbfa
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Some library versions are outdated since the release of Debian Buster.
With this commit the required libraries versions will match as close as
possible the versions available in the current Debian stable release
(Buster).
Also, the requirements were tested against a Windows Python 3.7 to
ensure that a "pip install -r" can be used without the need of a CPP
compiler.
As Babel format_time now returns 'HNE' (Heure Normale de l'EST) for Fr
locale instead of the zone offset, the test is adapted.
Finally the babel.dates is explicitely imported, otherwise the proper
import of this submodule is relying on a side effect.
closesodoo/odoo#43106
X-original-commit: 32e455bf72980e6330871aa9cd99c26c6e1225d7
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Fix a mixup between `bounced_msg_id` that is sometimes tought as a list
of string or directly as a string.
Now `bounced_msg_id` is always a list or `False` if there is no bounce.
opw-2157793
closes#43084closesodoo/odoo#43091
X-original-commit: b0e0cee9f9623d972c4dee26d3536600dc95f276
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When accessing stock_barcode module to validate pickings, is not
possible to add floating point quantities for any localizaton which uses
',' as decimal separator.
The numeric field is now defined via browser tags <input="numeric"> to
make the numeric keyboard popup automatically on mobile devices
(commit 8f5840369b28962ab2be9edfce7331a836c3df22)
Adding the override to avoid further processing when the input
is already anumber
opw-2154657
closesodoo/odoo#42748
X-original-commit: 1ccc60deeb067f8d461d48cbf51719317c22cb90
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commit reverts a previous fix because we found a better one
in enterprise.
So we don't need this line anymore.
opw-2071605
Task ID: 2152160
closesodoo/odoo#43102
Related: odoo/enterprise#7647
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The matrix data structure awaited by the server is the following :
{
question_id: {
'row_id_1': ['col_id1', ..., 'col_idn'],
'row_id_n': ['col_id1', ..., 'col_idn'],
'comment': 'This is a comment',
}
}
Before this commit, the comment was encapsulated into a dict, into an array,
with an incorrect key :
-> 'questionId_comment': [{'comment': 'This is a comment'}]
This was leading to 2 errors :
- A traceback when nothing is selected in the matrix options
- Comment is never saved.
After this commit, the comment is correctly given to and extracted by the
server. So the comment is saved and the traceback is avoided.
Task ID: 2152223
closesodoo/odoo#43086
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
This commit fixes the "back button" that appears when the user is taking the
survey, allowing to go back to previous pages or questions.
There was a typo in the name of the parameter.
Task 2152223
closesodoo/odoo#43003
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
From the PoV of the customer, there is no difference between an
authorized payment and a captured payment; they should get redirected to
the confirmation page in both cases.
closesodoo/odoo#42780
X-original-commit: 452676737dd657a5d31a88fa89cc136cbe69b96a
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
This feature has been lost when removing the account.invoice model.
closesodoo/odoo#43060
--task: 2154792
X-original-commit: 7615030fb293356fc5540ba65afa66ff71b207c1
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- In a multi currency company, create an invoice with the domestic
currency ($);
- Add a product (500$) with taxes;
- Change the currency to a foreign one (€);
- The product don't change of amount but only of currency (500€);
- Save the invoice, and print it.
Before this commit, the base_amount_tax of the tax wasn't be updated.
Note that the base_amount_tax it should be expressed in domestic
currency. As this field didn't update in this case, the base_amount_tax
is expressing the amount in foreign currency. As this amount is supposed
to be in domestic, for the sake of the reports, it's change in currency
of the invoice (in this case the foreign one), and it's shown in the
report. The amount shown is not correct.
Now, the base_amount_tax is recompute and setted in domestic currency.
opw-2157853
closesodoo/odoo#43071
X-original-commit: 226a1155124e890d00e33968feb43b9fd6b99fa5
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
With this commit, we can now say "on preview/selection of a widget,
also preview/selection these other widgets". For this, add a
`data-trigger` with comma-separated widget names.
A `data-trigger-value` can also be used to indicate the values these
other widgets should have during preview/selection... but this currently
only works for colorpicker widgets thanks to a big big hack that should
be improved later.
Part of https://github.com/odoo/odoo/pull/42986closesodoo/odoo#42986
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* website
This commit is simply about factorizing the code some more and making
sure the user value widgets always trigger a meaningful 'previewMode'
value.
Part of https://github.com/odoo/odoo/pull/42986
* website
This commit is simply about making the related method public instead of
private (allow to better see the diff in upcoming improvement commits).
Part of https://github.com/odoo/odoo/pull/42986
Instead of triggering three different events 'user_value_change',
'user_value_preview' and 'user_value_reset', user value widgets in the
left panel now trigger only one event: 'user_value_update' with a
'previewMode' parameter being false, true or 'reset'.
This allows to simplify the code.
Part of https://github.com/odoo/odoo/pull/42986
_log_next_activity was on stock.rule and should have been
@api.model. So it should rather be on product template but
it's probably not necessary to have a function for it since
it's only used by orderpoint process.
Create RFQ with an order by date in futur. It will allow to
discuss RFQ before validate them and to be in time for the need.
today Order by Sheduled date of receipt
|_______________|___________________|_____________________|
days to purchase vendor LT security days
Task: 1849912
When the scheduler runs, each orderpoint will check the forecast stock
for an infinite time. As example, if we plan a receipt of 10 products in
4 months and need to deliver 5 products next month, procurement will not
be launched since we have a forecasted quantity of 5.
In order to improve it, the orderpoint will compute the total lead days
from rules, suppliers/production delays, security days,...
Those lead days will be added to today in order to know at which date
the forecast stock should be checked and trigger the replenish document
for today in order to be delivered at the correct date.
Task: 1849912
Currently orderpoint run one request at a time. However it's not
efficient since compute are some private methods could be executed
one time in batch instead of record by record.
The strategy in order to improve it is:
- Still cut the orderpoints in batch of 1000 (usefull when using a new
cursor with intermediate commit)
- For each batch of 1000, create a list of procurement values and run
them in batch (commit a2a6b099a4 for more info)
- Each time a procurement exception is raised, catch the failing
orderpoint and rollback to the state before run. Remove the failing
order point from the current set and run it again.
- run method try to catch a maximum errors by continuing to process even it
finds error in order to stack them. It would avoid to run the same set
again and again each time an error is raised.
test_orderpoint_1 took 975s before this patch and 100s after.
Task: 1849912
Currently when a procurement fail it will raise a user error.
Some function as run in stock_rule catch the errors and merge
them in a single error.
Also since commit a2a6b099a4 procurements
are executed in batch and in some cases, we would like to have more
information about the error. For example in orderpoint we would like to
know which orderpoint is responssible for which error.
It would also be possible to return an object with the details but
procurements pass through a lot of different method that already have
their own return signature and a simple exception is easier to manage.
Task: 1849912
Orderpoint reference are only set on the first object that is created
from the procurement request. However sometimes we would like to access
it from further object or define another behavior if we come from an
orderpoint.
Now that the we propagate the orderpoint_id, it's important to ignore
po line with an orderpoint AND a chained stock move, else the quantities
will be counted twice by the orderpoint in a 2 steps receipt scenario
Task: 1849912
- lead_days: number of days to add from today in order to define the
procurement request date.
- lead_type purpose is to define if supplier delays should be added
to procurement request date.
Those fields are problematic with the onboarding. The purpose is to
replace them with an automatic computation.
Task 1849912
This will be use to make testing of the MiPyme FCE document types
closesodoo/odoo#43080
X-original-commit: 4365bd25512082bfd70229272c7248720f0383ca
Signed-off-by: Josse Colpaert <jco@openerp.com>
Alexandre Kühn