Monday, January 13, 2020
33 changes · master
Enhancements to existing features
Manufacturing procurement now handles products whose bill of materials contains only services without raising unnecessary warnings about missing components. This avoids confusing scheduler messages and prevents unneeded manufacturing order confirmation when there are no stockable components to process.
Original PR description
Previously when the BoM on a product do not have components but only services. Then during scheduler a log was posted on the product explaining that components are required. However since this process is possible in another usecase it should be possible with procurement. The only difference is that procurements confirm records in order to propagate. In this case since there is no components and services are not propagate with procurements, it's not needed to confirm the MO. Task: 2170845
Surveys now move between the start screen, questions, and completion screen without reloading the page, creating a smoother experience for respondents. The update also improves answer saving when time runs out, starts timers only after the survey begins, and prevents duplicate submissions after completion.
Original PR description
Purpose ======= To have a better UX, the transition between questions in a survey should not be done by loading another page, but by loading next questions in AJAX. Specifications =========== Do the…
Purpose ======= To have a better UX, the transition between questions in a survey should not be done by loading another page, but by loading next questions in AJAX. Specifications =========== Do the transition in ajax, no more page loading: - During submit, load and display next questions in a smooth transition (fade in / fade out). - Include start and end screen of the survey inside the survey form (same process, load next screen in smooth transition) - Integrate timer and start only after start survey. - Integrate breadcrumb and handle manually (at frontend) transition about clickable / active / inactive breadcrumb item. Make the survey breadcrumb a widget to ease the navigation transitions and updates. - Validate questions at frontend before sending data for submit. (to avoid fading out then fading in the same questions with error messages) Also include some improvements and fixes : - Save questions on time limit reached, to take into account unsubmitted answer (if user does not have time to click on submit) - Block submit if survey has been already completed by the user. - Do not use previous id on one page mode (fix) - Remove display mode for simple choice question : that will prepare the next redesign of survey and allow to handle simple choice in a more standard way for all kind of question types. See sub commit for more detail. Task ID : 2152223
The mobile settings tabs now use the same cleaner style as the mobile kanban view, giving users a more consistent experience on phones and tablets. Shared mobile styling code was reorganized to make future maintenance easier without changing core business workflows.
Original PR description
With this commit, we apply the same style used by the mobile kanban view to the settings tabs. To made easier the code maintainability we create a Javascript mixin to allow the code sharing between these two cases.
Mail channels can now be archived or restored when they are no longer needed. Archived channels are removed from the Discuss channel list, helping users keep their workspace cleaner while retaining channel history.
Original PR description
Description of the issue/feature this PR addresses: Be able to archive/unarchive a channel. Current behavior before PR: there is no any option to archive a channel. Desired behavior after PR is merged: there will be archive/unarchive option for mail.channel object Task: https://www.odoo.com/web?#id=2155386&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.38935fe59b53aefe84b597062dea2ab6 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
Users can now add and view a contact’s bank account details directly from the Contacts app, even when Invoicing or Accounting is not installed. This removes an unnecessary dependency and makes basic banking information easier to manage for contact records.
Original PR description
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
Settings tabs on mobile now use a clearer, scrollable tab style similar to the mobile kanban view. This makes it faster for users to find and open the settings section they need, while also fixing a small search icon alignment issue.
Resolved issues and error corrections
This change removes an obsolete field from unit of measure categories that was causing errors when users created new categories. It simplifies category setup and prevents avoidable creation failures.
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. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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#43137This 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.
The 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