Example:
User 1 has access to company A
User 2 has access to company B
Customer 1 is shared, has user 2 as their Salesperson
Try to create a SO for Customer 1 as User 1
=> access rights issue, the quote is trying to set User 2
as the salesman of the quote but cannot because of
base.res_users_rule
This commit makes this flow possible by sharing users
if they're not portal.
closesodoo/odoo#43190
X-original-commit: ebc8d85d383643c1d4d2aa6723bc7a589c7d1c68
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Before this commit, there were some tests checking
how long it took to compute a bunch of templates
Those asserted a time limit, which is undeterministic
After this commit, those performance tests
are not executed as standard anymore
Moreover, only asserts on ratios between computations is done
and deemed relevant.
closesodoo/odoo#43189
X-original-commit: 329fdf3961ea9e6eddbcba7a78d72102d2d08ac1
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit enables archived mail channels.
Archiving one also removes it from channel list in Discuss.
Task-Id 2155386
closesodoo/odoo#42743
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit adds "Next Activities" on kanban card of partners,
like on the app Contact.
Task-Id 2152180
closesodoo/odoo#41793
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This removes the measure_type field which has become unused and
causes issues when users try to add new uom categories.
Task-2043927
closesodoo/odoo#41056
Related: odoo/enterprise#6945
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit:
If neither Invoicing nor Accounting are installed, users are stuck with menus
items to create bank-related informations (Banks and Bank accounts). They won't
be able to set these information directly on their contacts.
After this commit:
The Bank Accounts part of the Invoicing tab has been moved from the `account`
module to `base`, so it's now visible in the partner form even when only
`contacts` is installed
Task ID: 2126832
closesodoo/odoo#40563
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If a user changes the company of a product, we should make sure that the
product was not sold in another company in the past; otherwise it could
make some orders un-invoiceable.
closesodoo/odoo#43187
X-original-commit: 069f04935ebc22c15b4903b526401ebf0df830a3
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
It happens that people modify the product on done stock.move.line
(it's not possible without customisation, at least allow to import or
to modify product and lot_id in the same view).
During the write on stock.move.line only the lot,locations,package and
owner are update on the quant. Not the product since it's not suppose to
be modify. It leads to a stock.move.line with a correct information but
a total mess on the quants with a lot updated and the previous product.
Since the product is not modified, the product on the quant and the
product on the lot linked to the same quant are different.
closesodoo/odoo#43180
Task: 2119471
X-original-commit: f2a4f7013742cc2cd45264daddaae8b457ca0eb6
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When switching a invoice to a refund, the bank account to which the move
should be paid should be removed: while it (might) contain the partner's
bank account before, when becoming a refund it makes no sense to keep
the partner's bank account as the recipient.
closesodoo/odoo#43176
X-original-commit: e94234f435622b7de00c917ca7c6302fd6c92881
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Before this commit, the invoice creation flow of a sales order checked
if the amount of the generated invoice was positive or negative - if it
was negative, then the invoice would be converted to a refund instead.
Unfortunately, this check was done before the move was actually created
\- meaning that the only way to compute the total of the move was to
multiply the quantities and unit prices of what was about to be included
in the move - ignoring taxes altogether. Since taxes would then be
applied during the move's creation, you could in fact have a refund that
ended up being negative because some products would end up with
different taxes.
A simple (although weird) example would happen if you registered a
down payment that was actually greater than the subtotal of your
quote (but lower than the total with taxes included).
Example:
Create a quote for a 100$ product with 15% tax
Register a downpayment of 105$ and validate that invoice
Invoice the rest:
=> you end up with a refund of -10$, while you should have a 10$
invoice instead.
Since the downpayment did not have taxes, the second invoice was
computed as being negative (100$ for the product - 105$ to deduce the
down payment), even though after the 15% tax gets applied on the product
(but not on the downpayment), the invoice is actually positive.
This commits moves the switch from invoice to refund to *after* the move
actually gets created, ensuring taxes are taken into account.
X-original-commit: eefe27b112e2ffd35a834f03a188625a5d6ea5f2
Before this commit: all dialogs would go through the static method (OwlDialog.hide)
when destroyed, regardless of wether they had been opened or not.
Now, only dialogs having an 'el' property set (= having been opened) will use
the 'hide' method.
Task 2170705
closesodoo/odoo#43124
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the test 'all messages in "Inbox" in "History"
after marked all as read' had non-deterministic failures.
More precisely, it crashed on either assertion "there should be 30
messages in History" or "there should be 40 messages in History",
both resulting to 0 messages in History instead.
Unfortunately, as of the date of this commit, we still do not
understand why it rarely fails. In the meantime, we have decided to
make these errors less likely to happen, by waiting much longer
before the assertions. We are aware that this is a poor solution,
but this is much better than skipping the test, until we find and fix
this issue at a later moment.
Closes#43072
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
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
Damien Bouvy