Thursday, September 23, 2021
36 changes · master
Enhancements to existing features
The Discuss start-a-meeting flow now adapts better to different screen sizes and shows guest names correctly when starting a live conference. This makes joining or launching meetings smoother and clearer for users.
Original PR description
- Improve responsivity of WelcomeView and MediaPreview - Reuse MediaTrackConstraints already defined in mail.rtc - Properly display guest's name when starting a live conference
CRM forecast filters now work more independently from the surrounding page setup, making forecast views easier to configure and maintain. This reduces hidden dependencies and helps ensure forecast filtering behaves consistently when users group opportunities by date-related fields.
Resolved issues and error corrections
The wording for a sale receipt setting was corrected from “Active” to “Activate.” This makes the option clearer for users configuring accounting settings and avoids confusion caused by the typo.
Original PR description
Fix typo under sale receipt in res_config_settings_views. Active to create sale receipt ---to---> Activate to create sale receipt task: 2643691
Miscellaneous changes
This commit removes the default group by User for the Tasks Analysis report, which was active once one clicked on "Open Tasks" in the Project Update Kanban view. Issue : The graph view of report.project.task.user is not able to render the project_id>user_id groupby since the number of rows to display is to high. After considering improvements client-side (e.g. drop last groupby when there are too many datasets to render), we concluded that the case of report.project.task.user is rat
Original PR description
This commit removes the default group by User for the Tasks Analysis report, which was active once one clicked on "Open Tasks" in the Project Update Kanban view. Issue : The graph view of…
This commit removes the default group by User for the Tasks Analysis report, which was active once one clicked on "Open Tasks" in the Project Update Kanban view. Issue : The graph view of report.project.task.user is not able to render the project_id>user_id groupby since the number of rows to display is to high. After considering improvements client-side (e.g. drop last groupby when there are too many datasets to render), we concluded that the case of report.project.task.user is rather isolated. The real issue is that this 'complex' two-level groupby is forced in the view itself, making it unusable on larger databases (e.g. next.odoo.com). On top of that, project_id and user_id are usually dependent dimensions (users are usually working in the same few projects). task-2588087 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#76966 Forward-Port-Of: odoo/odoo#73299
Re-enabling manufacturing operations now restores previously active operations instead of leaving them archived. This prevents production setup data from disappearing after businesses temporarily disable and later re-enable the operations setting.
Original PR description
Following https://github.com/odoo/odoo/pull/66108/, de-activating the operation setting archives all operations. The problem is that after re-activation of the operation setting, operations that were active before were not un-archived. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves how mail templates are rendered and includes several fixes across signing, point of sale, spreadsheets, forecasting, and planning. Business users should see fewer errors when sending signature requests, clearer discount display, more reliable spreadsheet pivots, and better planning totals and layout.
This fixes a duplicated incoterm setting that appeared under the Intrastat section. Users will now see the option only once, reducing confusion when configuring accounting and reporting settings.
Original PR description
The incoterm option is duplicated under the intrastat subheading. This as a result of it being added in res_config_settings when it is already added in odoo/account res_config_settings , it is the only thing added in this file, so it makes sense to remove the file.
https://github.com/odoo/enterprise/pull/20682 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#76138
Original PR description
https://github.com/odoo/enterprise/pull/20682 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#76138
The translation alert will now appear in the wizard, it will no longer appear. Technical: res_id is undefined in the wizard Like : { 'undefined': { 'displany_name / name': { change_default: false company_dependent: false depends: [] id: null manual: false translate: true --- } } } Forward-Port-Of: odoo/od
Original PR description
The translation alert will now appear in the wizard, it will no longer appear.
Technical:
res_id is undefined in the wizard
Like :
{
'undefined': {
'displany_name / name': {
change_default: false
company_dependent: false
depends: []
id: null
manual: false
translate: true
--- }
}
}
Forward-Port-Of: odoo/odoo#76298We were trying to sort a list of date with potentially falsy elements in the list, causing a crash while trying to compare a date object with a bool. This commit just makes the check that all dates are not falsy before attempting to sort. Forward-Port-Of: odoo/odoo#76959
Original PR description
We were trying to sort a list of date with potentially falsy elements in the list, causing a crash while trying to compare a date object with a bool. This commit just makes the check that all dates are not falsy before attempting to sort. Forward-Port-Of: odoo/odoo#76959
part of task-2634175 Forward-Port-Of: odoo/odoo#76969
Original PR description
part of task-2634175 Forward-Port-Of: odoo/odoo#76969
Reproduce : - CRM. - Go to a task and schedule next activity. - Then mark this activity as done. - Write a feedback. Result : - Server error traceback Solution : - The written feedback is added after translating "Feedback: " is present. opw-2641747 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-Por
Original PR description
Reproduce : - CRM. - Go to a task and schedule next activity. - Then mark this activity as done. - Write a feedback. Result : - Server error traceback Solution : - The written feedback is added after translating "Feedback: " is present. opw-2641747 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#76938
Before this commit, when a "100% height" snippet was set in a popup snippet, it was still computed to take full-screen height minus the size of the navbar. Now, it will properly be full-height. Forward-Port-Of: odoo/odoo#76897
Original PR description
Before this commit, when a "100% height" snippet was set in a popup snippet, it was still computed to take full-screen height minus the size of the navbar. Now, it will properly be full-height. Forward-Port-Of: odoo/odoo#76897
Before this commit, the "purple" main menu navbar disappeared before the editor was loaded (after clicking on the "Edit" button). task-2652381 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#76889
Original PR description
Before this commit, the "purple" main menu navbar disappeared before the editor was loaded (after clicking on the "Edit" button). task-2652381 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#76889
This commit allows anyone to create a new mail.channel by visiting the URL /chat/\<token\>[\/<channel_name>], providing that the mail.chat_from_token system parameter is set. This is useful in some situations where new channels need to be created quickly as needed by anyone without special permissions (eg, during the Odoo experience) task-2648580 Forward-Port-Of: odoo/odoo#76943
Original PR description
This commit allows anyone to create a new mail.channel by visiting the URL /chat/\<token\>[\/<channel_name>], providing that the mail.chat_from_token system parameter is set. This is useful in some situations where new channels need to be created quickly as needed by anyone without special permissions (eg, during the Odoo experience) task-2648580 Forward-Port-Of: odoo/odoo#76943
Ask for camera/microphone access when landing on the WelcomeView of a channel created via the "Start a meeting" feature. Part of task 2651831. Forward-Port-Of: odoo/odoo#76951
Original PR description
Ask for camera/microphone access when landing on the WelcomeView of a channel created via the "Start a meeting" feature. Part of task 2651831. Forward-Port-Of: odoo/odoo#76951
The amount on generated COGS lines can have the UoM factor applied two times. For example, if we have a product costing 1$ per item and we sell it by pack of 12 ("Pack" UoM) we will have 1$\*12\*12=144$ instead of 1$*12=12$ 0/ Go to a V14 runbot 1/ Create a company which use COGS (eg. Mexican accounting) 2/ Have a storable product priced at 1.5$ from a product category with Costing Method as "First In First Out (FIFO)" and Inventory Valuation as "Automated" 3/ Create a UoM 12 times bigger
Original PR description
The amount on generated COGS lines can have the UoM factor applied two times. For example, if we have a product costing 1$ per item and we sell it by pack of 12 ("Pack" UoM) we will have…
The amount on generated COGS lines can have the UoM factor applied two times. For example, if we have a product costing 1$ per item and we sell it by pack of 12 ("Pack" UoM) we will have 1$\*12\*12=144$ instead of 1$*12=12$
0/ Go to a V14 runbot
1/ Create a company which use COGS (eg. Mexican accounting)
2/ Have a storable product priced at 1.5$ from a product category with Costing Method as "First In First Out (FIFO)" and Inventory Valuation as "Automated"
3/ Create a UoM 12 times bigger than the default Unit (eg. 12 Pack)
4/ Create a purchase order costing 50$ for 50 Unit of the product => cost of the product should be 1$
5/ Create a new purchase order for 50 Unit but costing 0$ (like if got free products from supplier)
6/ Create sale order for 50 units of the product, validate the transfert and create/confirm the invoice => computed COGS amount is 50$ on the invoice => ok
7/ Create a sale order using the "12 Pack" UoM, validate transfert and create/confirm invoice => computed COGS is 144$ => nok
opw-2503368
Forward-Port-Of: odoo/odoo#76420This commit removes the action_confirm from the run_manufacture to do it only after all the orderpoints have been processed. In case a production, created in run_manufacture, triggers procurements for one of its component. And those procurements have the same parameters than another one still not run because after the manufacture one in the queue. This new procurement will replenish its quantity plus the other procurement's one. That means too much quantity will be replenished. Des
Original PR description
This commit removes the action_confirm from the run_manufacture to do it only after all the orderpoints have been processed. In case a production, created in run_manufacture, triggers procurements for one of its component. And those procurements have the same parameters than another one still not run because after the manufacture one in the queue. This new procurement will replenish its quantity plus the other procurement's one. That means too much quantity will be replenished. 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#76902 Forward-Port-Of: odoo/odoo#76549
Forward-Port-Of: odoo/odoo#76747
Original PR description
Forward-Port-Of: odoo/odoo#76747
…n Israel. This commit include the following changes: taxes, fiscal positions, and chart of accounts @jco-odoo I have created a new PR with one commit according to the feedback. Kind regards, -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#75971
Original PR description
…n Israel. This commit include the following changes: taxes, fiscal positions, and chart of accounts @jco-odoo I have created a new PR with one commit according to the feedback. Kind regards, -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#75971
get_ip and get_mac_address respectively try to get the IP and MAC from the IoT box's active network interface. If the interface isn't fully up yet (due to waiting on a slow DHCP server response for example), both functions can end up raising a KeyError exception since neither interface has a value. This can be bad if it's uncaught and happens in something like the Manager thread, potentially killing it as a result. This can then disrupt the rest of the application. The network being gon
Original PR description
get_ip and get_mac_address respectively try to get the IP and MAC from the IoT box's active network interface. If the interface isn't fully up yet (due to waiting on a slow DHCP server response for example), both functions can end up raising a KeyError exception since neither interface has a value. This can be bad if it's uncaught and happens in something like the Manager thread, potentially killing it as a result. This can then disrupt the rest of the application. The network being gone for a bit or slow is something that can happen during everyday use, so we should be robust against it. Since the box can't do any useful work without an active network connection, this fix keeps retrying until one of the interfaces comes back up. opw-2357144 Forward-Port-Of: odoo/odoo#76840
The check added in 643e093a4bc9d46973705831697036b56a89b143 was too strict in case a purchase order was created from an orderpoint triggering multiple rules. The orderpoint's location could be below another warehouse that the first rule's location and thus raising the error. 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
Original PR description
The check added in 643e093a4bc9d46973705831697036b56a89b143 was too strict in case a purchase order was created from an orderpoint triggering multiple rules. The orderpoint's location could be below another warehouse that the first rule's location and thus raising the error. 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#76498
PURPOSE The Event Sub-menu should be showing after installing the website_event module. The purpose of this commit is to show the Event Sub-menu. SPECIFICATIONS Right now, when we only have the website_event installed and there are no other regular(view-based) customize menus available, we won't have a divider div tag. And the current code tries to push our menu after the first divider and thus fails due to no divider available. This fixes the issue simply by adding the div and p
Original PR description
PURPOSE The Event Sub-menu should be showing after installing the website_event module. The purpose of this commit is to show the Event Sub-menu. SPECIFICATIONS Right now, when we only have the website_event installed and there are no other regular(view-based) customize menus available, we won't have a divider div tag. And the current code tries to push our menu after the first divider and thus fails due to no divider available. This fixes the issue simply by adding the div and push the menu after the divider. This is the goal of this commit. LINKS PR #76633 Task-2616588 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#76633
There was 3 keys for the same icon 😠 while one of them is usually usedin normal text. For example: ``` - Item 1: - Item 2: - Item 3: ``` After sending message, the result would be ``` - Item 1: - Item 2: - Item 😠 ``` This PR removes one of the above to keep the other two. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#77027
Original PR description
There was 3 keys for the same icon 😠 while one of them is usually usedin normal text. For example: ``` - Item 1: - Item 2: - Item 3: ``` After sending message, the result would be ``` - Item 1: - Item 2: - Item 😠 ``` This PR removes one of the above to keep the other two. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#77027
Fixes a traceback when generating work entries. How to reproduce: - Create a contract with a working schedule with 0 attendances - Set the contract as running - Make sure you have another contract for another employee running on the same period, this one must have attendances - Go to the work entries views, this should generate working entries for the viewable dates - If the work entries were already generated, go to a month where they are not generated yet, you should have the tr
Original PR description
Fixes a traceback when generating work entries. How to reproduce: - Create a contract with a working schedule with 0 attendances - Set the contract as running - Make sure you have another contract for another employee running on the same period, this one must have attendances - Go to the work entries views, this should generate working entries for the viewable dates - If the work entries were already generated, go to a month where they are not generated yet, you should have the traceback Task ID: 2654797 Forward-Port-Of: odoo/odoo#77049
Forward-Port-Of: odoo/odoo#76941
Original PR description
Forward-Port-Of: odoo/odoo#76941
In [1], we rewrote the effect feature in the wowl infrastructure. However, we lost something in the process: the "type" of effect (basically "rainbow_man" as it is the only implemented effect) became a mandatory param, whereas before it simply defaulted to "rainbow_man" when not set. As a consequence, previously defined effects in views could crash. This commit fixes that issue, and reworks a bit the feature by introducing a registry of effects, which easily allows to add new effects f
Original PR description
In [1], we rewrote the effect feature in the wowl infrastructure. However, we lost something in the process: the "type" of effect (basically "rainbow_man" as it is the only implemented effect) became…
In [1], we rewrote the effect feature in the wowl infrastructure. However, we lost something in the process: the "type" of effect (basically "rainbow_man" as it is the only implemented effect) became a mandatory param, whereas before it simply defaulted to "rainbow_man" when not set. As a consequence, previously defined effects in views could crash. This commit fixes that issue, and reworks a bit the feature by introducing a registry of effects, which easily allows to add new effects from the outside. An effect is a function that may return a Component (and its props) to display. Most of the diff in the tests is about moving files where they should be (the effect feature being in /core, the tests must be in core/ as well, and not depend on the webclient). [1] 0573acae2306bf5da2005852da9323ddc59e5431 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#76978
After the insertion/modification/removal of a global filter, we have to ensure the data source is correctly reloaded (i.e. has load data with the computed domain). Runbot report id 2148, 2127 and 2155 Forward-Port-Of: odoo/enterprise#21063
Original PR description
After the insertion/modification/removal of a global filter, we have to ensure the data source is correctly reloaded (i.e. has load data with the computed domain). Runbot report id 2148, 2127 and 2155 Forward-Port-Of: odoo/enterprise#21063
Now that we are officially approved we can set instagram as auto install. Purpose is to have all social sub modules automatially installed to ease discovering and use of social connectors. Task-2649088 Forward-Port-Of: odoo/enterprise#21062
Original PR description
Now that we are officially approved we can set instagram as auto install. Purpose is to have all social sub modules automatially installed to ease discovering and use of social connectors. Task-2649088 Forward-Port-Of: odoo/enterprise#21062
In order to know when we are fetching new accounts with the intent to add them or not, pass this information along to the proxy. Forward-Port-Of: odoo/enterprise#21029
Original PR description
In order to know when we are fetching new accounts with the intent to add them or not, pass this information along to the proxy. Forward-Port-Of: odoo/enterprise#21029
The exception handling added in 04a148f0f69 is using psycopg2.errors but it is not available in psycopg2 2.7.7 that is used in case of python_version < 3.8 (see https://github.com/odoo/enterprise/commit/04a148f0f6#r56936600) opw-2499702 Forward-Port-Of: odoo/enterprise#21095
Original PR description
The exception handling added in 04a148f0f69 is using psycopg2.errors but it is not available in psycopg2 2.7.7 that is used in case of python_version < 3.8 (see https://github.com/odoo/enterprise/commit/04a148f0f6#r56936600) opw-2499702 Forward-Port-Of: odoo/enterprise#21095
Before, the "Total revenue (NS)" on the report Financial Z was not correct. It only included cash payments. Now, it takes all payments into account (Cash + Bank). Forward-Port-Of: odoo/enterprise#21064
Original PR description
Before, the "Total revenue (NS)" on the report Financial Z was not correct. It only included cash payments. Now, it takes all payments into account (Cash + Bank). Forward-Port-Of: odoo/enterprise#21064
Following the introduction of multiple cancel reasons for the dispatched commands ( https://github.com/odoo/o-spreadsheet/commit/f314bd022d5a1fb9cb62c1a92cb433b1217dc6e6 https://github.com/odoo/enterprise/commit/2fd4d7df94d7cda176905564d1eaa46854232e37 ) Duplicated filter labels were not properly detected and subsequently notified as such to the end user. Task 2649217 Forward-Port-Of: odoo/enterprise#20987
Original PR description
Following the introduction of multiple cancel reasons for the dispatched commands ( https://github.com/odoo/o-spreadsheet/commit/f314bd022d5a1fb9cb62c1a92cb433b1217dc6e6 https://github.com/odoo/enterprise/commit/2fd4d7df94d7cda176905564d1eaa46854232e37 ) Duplicated filter labels were not properly detected and subsequently notified as such to the end user. Task 2649217 Forward-Port-Of: odoo/enterprise#20987
Purpose of the commit is to remove traceback while accessing 'SMS Marketing' menu of mass_mailing_sms aster uninstall marketing_automation module id:2629395 Forward-Port-Of: odoo/enterprise#20809
Original PR description
Purpose of the commit is to remove traceback while accessing 'SMS Marketing' menu of mass_mailing_sms aster uninstall marketing_automation module id:2629395 Forward-Port-Of: odoo/enterprise#20809
…e_get When failing to fetch the display_name of a record in a pivot formula, the error caught was simply stringified and cast as the error key of the formula. The error was not very explicit when read by a user ("Odoo Server Error") but it was also causing issues during the tests : we were catching the errors raised by the navigator while each navigator has its own way to describe those errors. For instance, in the tests, a TypeError was raised because we were trying to access a
Original PR description
…e_get
When failing to fetch the display_name of a record in a pivot formula,
the error caught was simply stringified and cast as the error key of the
formula.
The error was not very explicit when read by a user ("Odoo Server
Error") but it was also causing issues during the tests : we were
catching the errors raised by the navigator while each navigator has its
own way to describe those errors.
For instance, in the tests, a TypeError was raised because we were trying
to access a property of an undefined object. One can then verify by
testing `undefined.MyField` in several browser the following outputs:
Firefox 92.0 -> `TypeError: undefined has no properties`
Chrome < 93 -> `TypeError: Cannot read property 'display_name' of
undefined`
Chrome 93 -> `TypeError: Cannot read properties of undefined (reading
'displayName')`
Task 2653908
Forward-Port-Of: odoo/enterprise#21056https://github.com/odoo/odoo/pull/76138 Forward-Port-Of: odoo/enterprise#20682
Original PR description
https://github.com/odoo/odoo/pull/76138 Forward-Port-Of: odoo/enterprise#20682