Monday, January 13, 2020
26 changes · master
Enhancements to existing features
The Board menu is now handled the same way as other Odoo menus during updates. This helps ensure menu changes can be applied consistently when the system is upgraded, reducing the chance of outdated menu behavior persisting.
Original PR description
All other menus are in noupdate=0 Remove the noupdate on the Board menu Fixes odoo/odoo#32828
Partner cards now show the next scheduled activity directly in the kanban view, matching the experience already available in Contacts. This helps users spot follow-ups faster without opening each record.
Original PR description
Task:https://www.odoo.com/web?#id=2152180&action=327&model=project.task&view_type=form&menu_id=4720 Pad:https://pad.odoo.com/p/r.ea472513b0959636a1bc99ab3a3ee3aa
Resolved issues and error corrections
This update stabilizes internal automated tests for Odoo's messaging and web components by fixing timing-related failures and improving how test errors are handled. It helps maintain release quality by reducing false test failures without changing end-user features.
Miscellaneous changes
If we have a many2many_tags widget that is writable then becomes readonly, some data will still be present and possibly cause error. For example, if we have an attribute: `<field widget="many2many_tags" attrs="{'readonly': 'condition'}"/>` if the field goes from editable to readonly, we have on the field a `many2one` attribute that will for example cause an error in `getFocusableElement` because we try to focus on removed element. TODO: add a test opw-2154471 Forward-Port-Of:
Original PR description
If we have a many2many_tags widget that is writable then becomes
readonly, some data will still be present and possibly cause error.
For example, if we have an attribute:
`<field widget="many2many_tags" attrs="{'readonly': 'condition'}"/>`
if the field goes from editable to readonly, we have on the field a
`many2one` attribute that will for example cause an error in
`getFocusableElement` because we try to focus on removed element.
TODO: add a test
opw-2154471
Forward-Port-Of: odoo/odoo#43137The website editor now correctly previews what happens when a color picker value is reset. This helps configuration rules react properly before changes are applied, reducing misleading previews for users editing pages.
Original PR description
This is important so that trigger-value works (see https://github.com/odoo/odoo/commit/e590609ebb429c6254766aa1fd8cab3ce3fd4c74)
This fixes an issue where the web interface tried to hide dialogs even if they had never been shown. It helps avoid unnecessary dialog handling and potential interface errors when closing or destroying popup windows.
Original PR description
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
Field labels and help text were made consistent where the same business field appears across related apps. This prevents translations from changing depending on which modules are installed, improving reliability for multilingual users.
Original PR description
if one module does ```python foo = fields.Char(string="Foo") ``` and another module inherit of the same model and does ```python foo = fields.Char(string="Bar") ``` The field can not properly be translated as the source term will change based on the installed module (and the information of which module specify an attribute is not kept on the ir.model.fields)
Several field labels and help texts were aligned so they remain consistent when multiple apps are installed. This prevents translation inconsistencies and gives users clearer, uniform wording across affected Odoo modules.
Original PR description
Following detected duplicates at odoo/odoo#42777
The unused measurement type field has been removed from unit of measure categories. This prevents errors when users create new categories and simplifies the setup process.
Original PR description
This removes the measure_type field which has become unused and causes issues when users try to create new uom categories Task-2043927 Description of the issue/feature this PR addresses: Removing the measure_type field in uom_category. Current behavior before PR: The field has to be empty when creating a new uom_category otherwise there's an error. Desired behavior after PR is merged: Deleting this field as it is unused and creates issues.
Task: https://www.odoo.com/web#id=2167610&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.c0eb8b47723482160354550345f71504 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#43141 Forward-Port-Of: odoo/odoo#42929
Original PR description
Task: https://www.odoo.com/web#id=2167610&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.c0eb8b47723482160354550345f71504 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#43141 Forward-Port-Of: odoo/odoo#42929
Since a refactoring (it was working at some point), `title` attribute on `we` elements would be lost when rendering actual DOM elements. We had 2 occurences of `title` on `we` elements: 1. s_countdown > What Should Happ.. > Show Message > fa-eye icon has a title 2. data-js `BackgroundPosition` (section) > fa-arrows has a title Also, incoming Cookies Bar task/PR will add a title on 'Hide For' option. Forward-Port-Of: odoo/odoo#43111
Original PR description
Since a refactoring (it was working at some point), `title` attribute on `we` elements would be lost when rendering actual DOM elements. We had 2 occurences of `title` on `we` elements: 1. s_countdown > What Should Happ.. > Show Message > fa-eye icon has a title 2. data-js `BackgroundPosition` (section) > fa-arrows has a title Also, incoming Cookies Bar task/PR will add a title on 'Hide For' option. Forward-Port-Of: odoo/odoo#43111
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. Forward-Port-Of: odoo/odoo#43168
Original PR description
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.
Forward-Port-Of: odoo/odoo#43168Before 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. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and
Original PR description
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. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42879
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. TODO: - [ ] adapt `.pot` files - [ ] check corner cases: writing on multiple products (multi-edit list view), writing `False`, something else? Forward-Port-Of: odoo/odoo#42584
Original PR description
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. TODO: - [ ] adapt `.pot` files - [ ] check corner cases: writing on multiple products (multi-edit list view), writing `False`, something else? Forward-Port-Of: odoo/odoo#42584
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 i
Original PR description
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. Task: 2119471 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#43150 Forward-Port-Of: odoo/odoo#42608
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
Original PR description
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…
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. Also, this commit removes some weird fix that tried to correct the bank account of the move depending on whether it was an invoice or refund. However it did that very poorly, only modifiying the last invoice values it found. Instead, I've moved this change of bank account in the method that switches the invoice to a refund. Forward-Port-Of: odoo/odoo#43085
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_t
Original PR description
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…
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.
TaskID: 2166237
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#43179Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#43136
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#43136
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42712 Forward-Port-Of: odoo/odoo#40305
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42712 Forward-Port-Of: odoo/odoo#40305
- 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 Description of the is
Original PR description
- 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 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#43119
### 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
Original PR description
### 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**
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#42854Task: https://www.odoo.com/web#id=2167610&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.c0eb8b47723482160354550345f71504 Forward-Port-Of: odoo/enterprise#7661 Forward-Port-Of: odoo/enterprise#7651
Original PR description
Task: https://www.odoo.com/web#id=2167610&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.c0eb8b47723482160354550345f71504 Forward-Port-Of: odoo/enterprise#7661 Forward-Port-Of: odoo/enterprise#7651
TaskID: 2157054 Forward-Port-Of: odoo/enterprise#7443
Original PR description
TaskID: 2157054 Forward-Port-Of: odoo/enterprise#7443
Issue - Mock outgoing mail server (e.g. MailHog) - Install Sign & Set up 2 languages (e.g. English/French) - Keep English & Set a customer language to French - Send a signature request to the customer Sent in English. Cause The context language is used, by default it's the actual user language. Solution Change the context language with the partner's one. OPW-2152131 Forward-Port-Of: odoo/enterprise#7654
Original PR description
Issue
- Mock outgoing mail server (e.g. MailHog)
- Install Sign & Set up 2 languages (e.g. English/French)
- Keep English & Set a customer language to French
- Send a signature request to the customer
Sent in English.
Cause
The context language is used, by default it's the actual
user language.
Solution
Change the context language with the partner's one.
OPW-2152131
Forward-Port-Of: odoo/enterprise#7654- Create a project, allow Planning - Create some planning - Archive the project An error is raised because the `active` field does not exist anymore on `planning.slot`. opw-2171008 Forward-Port-Of: odoo/enterprise#7665
Original PR description
- Create a project, allow Planning - Create some planning - Archive the project An error is raised because the `active` field does not exist anymore on `planning.slot`. opw-2171008 Forward-Port-Of: odoo/enterprise#7665
Forward-Port-Of: odoo/enterprise#7633 Forward-Port-Of: odoo/enterprise#7613
Original PR description
Forward-Port-Of: odoo/enterprise#7633 Forward-Port-Of: odoo/enterprise#7613