Monday, October 26, 2020
29 changes · master
Enhancements to existing features
The Repair module no longer defines an access permission that is already provided by the Stock module. This reduces duplicate configuration and keeps access management cleaner without changing what users can do.
Original PR description
Access of model `stock_production_lot` is already given to Stock User (With same id/name/group) at https://github.com/odoo/odoo/blob/master/addons/stock/security/ir.model.access.csv#L13 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
Resolved issues and error corrections
This fixes the mass mailing editor so that when users open the theme selection view, other editing panels are hidden. This reduces visual clutter and prevents confusion while choosing an email theme.
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
- Install website_sale - Go to Website > Products > Products and create a Product with "Tax 15.00%" (i.e. Product X) - Publish the Product on Website - Go to Invoicing > Configuration > Fiscal Positions - Create a first Fiscal Position: * Fiscal Position (Name): Fiscal Position A * Tax Mapping: Tax 15.00% => Tax 15.00% - Create a second Fiscal Position: * Fiscal Position (Name): Fiscal Position B * Tax Mapping: Tax 15.00% => Tax 0.00% - Create a Portal User (i.e. User X) - Go
Original PR description
- Install website_sale - Go to Website > Products > Products and create a Product with "Tax 15.00%" (i.e. Product X) - Publish the Product on Website - Go to Invoicing > Configuration > Fiscal…
- Install website_sale - Go to Website > Products > Products and create a Product with "Tax 15.00%" (i.e. Product X) - Publish the Product on Website - Go to Invoicing > Configuration > Fiscal Positions - Create a first Fiscal Position: * Fiscal Position (Name): Fiscal Position A * Tax Mapping: Tax 15.00% => Tax 15.00% - Create a second Fiscal Position: * Fiscal Position (Name): Fiscal Position B * Tax Mapping: Tax 15.00% => Tax 0.00% - Create a Portal User (i.e. User X) - Go to Contacts and edit User X to set his Fiscal Position to Fiscal Position A - Open another session and connect with User X - Go to online Shop and add Product X in the cart - Open "My Cart" => Taxes are displayed correctly - Process checkout and enter an address - Before paying, Review Order and remove Products from Cart - In first session, change Fiscal Position of User X to Fiscal Position B - In User X session, add again Product X in the cart - Open "My Cart" => Taxes are displayed as if the Fiscal Position has not been changed The Taxes are correctly displayed if the checkout is proccessed. It is just that "fiscal_position_id" of SO is not checked and recomputed at this step for this flow. opw-2300330 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#60560 Forward-Port-Of: odoo/odoo#60269
change Configure taxcloud, 2+ delivery carrier, card payment Go to the website shop Add product to cart Checkout with USA address On the Confirm Order page, the tax is computed via TaxCloud and shown on the right. Pay via payment acquirer site The Subtotal (without taxes) is sent to the Payment Acquirer instead of the Total This occur because when selecting delivery carrier coupon lines are recomputed. To be on the safe side with taxcloud, taxes are excluded before recomputing co
Original PR description
change Configure taxcloud, 2+ delivery carrier, card payment Go to the website shop Add product to cart Checkout with USA address On the Confirm Order page, the tax is computed via TaxCloud and shown on the right. Pay via payment acquirer site The Subtotal (without taxes) is sent to the Payment Acquirer instead of the Total This occur because when selecting delivery carrier coupon lines are recomputed. To be on the safe side with taxcloud, taxes are excluded before recomputing coupon lines, but never added in this specific flow. opw-2338103 opw-2362493 opw-2353048 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60512
Steps to reproduce the bug: - Let's consider a sellable product P published on the shop - Let's consider a portal user PU adding P in his wishlist W - Set P with sale_ok = False (meaning unsellable) - With PU try to see W Bug: A 430 error was raised because the product P was not sellable opw:2362184 Forward-Port-Of: odoo/odoo#60523
Original PR description
Steps to reproduce the bug: - Let's consider a sellable product P published on the shop - Let's consider a portal user PU adding P in his wishlist W - Set P with sale_ok = False (meaning unsellable) - With PU try to see W Bug: A 430 error was raised because the product P was not sellable opw:2362184 Forward-Port-Of: odoo/odoo#60523
When a snippet is out of the viewport or hidden, the overlay should not be visible. Two distinct cases we had: - When the page is scrolled, the header is sometimes hidden thanks to tranform: translate(0, -100%); for some kind of effect -> the header is thus still visible but out of the viewport, any selected snippet inside that header would still have this overlay enabled so we would see the move and delete button on the top of the screen. - When the page is scrolled, with the
Original PR description
When a snippet is out of the viewport or hidden, the overlay should not be visible. Two distinct cases we had: - When the page is scrolled, the header is sometimes hidden thanks to tranform: translate(0, -100%); for some kind of effect -> the header is thus still visible but out of the viewport, any selected snippet inside that header would still have this overlay enabled so we would see the move and delete button on the top of the screen. - When the page is scrolled, with the vertical header, some part of the header are hidden for the affixed version. If any snippet in those hidden elements was selected, the overlay is still visible floating. task-2312878 Forward-Port-Of: odoo/odoo#58383
Before this commit, There would be Traceback (AttributeError: 'bool' object has no attribute 'date') on `Confirm Receipt Date` If order has no `Receipt Date`. Now, Button `Confirm Receipt Date` will be hidden if there is not `Receipt Date` to confirm. Closed #60222 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 Fo
Original PR description
Before this commit, There would be Traceback (AttributeError: 'bool' object has no attribute 'date') on `Confirm Receipt Date` If order has no `Receipt Date`. Now, Button `Confirm Receipt Date` will be hidden if there is not `Receipt Date` to confirm. Closed #60222 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#60659
Create a sale order with a service configured with - Service Invoicing Policy: Timesheets on tasks - Service Tracking: Create a new project but no task Save and confirm. Access the project and the tasks via smart button. Create a new task. The task will not be saved under the current project because there is no data reference in context. opw-2355547 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60413 Forward-Por
Original PR description
Create a sale order with a service configured with - Service Invoicing Policy: Timesheets on tasks - Service Tracking: Create a new project but no task Save and confirm. Access the project and the tasks via smart button. Create a new task. The task will not be saved under the current project because there is no data reference in context. opw-2355547 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60413 Forward-Port-Of: odoo/odoo#59752
This commit updates owl from v1.0.12 to v1.0.13 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#60696 Forward-Port-Of: odoo/odoo#60691
Original PR description
This commit updates owl from v1.0.12 to v1.0.13 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#60696 Forward-Port-Of: odoo/odoo#60691
- Create a user A with access rights to Project set as 'User' - As user A, add a follower to a task An AccessError is raised. It happens because `allowed_user_ids` has the group `project.group_project_manager`. opw-2369674 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#60702
Original PR description
- Create a user A with access rights to Project set as 'User' - As user A, add a follower to a task An AccessError is raised. It happens because `allowed_user_ids` has the group `project.group_project_manager`. opw-2369674 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#60702
Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working. 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#60631 Forward-Port-Of: odoo/odoo#60604
Original PR description
Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working. 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#60631 Forward-Port-Of: odoo/odoo#60604
This commit adds an easy improvement fixing a page speed warning: the font awesome font (declared in a font-face in assets_common) can be preloaded. The only problematic point was that font-awesome defines the font by a series of URL using different font formats. Only one can be preloaded (otherwise you would load files for no reason). As all Odoo supported browsers use the woff2 format, we only preload that one. At the cost of a warning for other browsers which use a different format.
Original PR description
This commit adds an easy improvement fixing a page speed warning: the font awesome font (declared in a font-face in assets_common) can be preloaded. The only problematic point was that font-awesome defines the font by a series of URL using different font formats. Only one can be preloaded (otherwise you would load files for no reason). As all Odoo supported browsers use the woff2 format, we only preload that one. At the cost of a warning for other browsers which use a different format. task-2350647 Forward-Port-Of: odoo/odoo#60588
Currently when unbuild a MO, we create journal entries the same as receiving components (add credit to input account) and deliver finished product (add debit to output account). But since the unbuild is just a revesal of the MO, the journal entries should alse be revesals. In this commit, when unbuild a MO, for the journal entry about component change, we add credit to the output account, and for the journal entry of finished product change, we add debit to input account make sure the
Original PR description
Currently when unbuild a MO, we create journal entries the same as receiving components (add credit to input account) and deliver finished product (add debit to output account). But since the unbuild is just a revesal of the MO, the journal entries should alse be revesals. In this commit, when unbuild a MO, for the journal entry about component change, we add credit to the output account, and for the journal entry of finished product change, we add debit to input account make sure the journal entries are also reversals. Task 2312828 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#58150
This commit adds a test for the fix odoo/odoo/pull/58769 that ensures that the chatter is properly cleared when creating a new record. task-2348472 Forward-Port-Of: odoo/odoo#60594
Original PR description
This commit adds a test for the fix odoo/odoo/pull/58769 that ensures that the chatter is properly cleared when creating a new record. task-2348472 Forward-Port-Of: odoo/odoo#60594
Before this commit, completing an activity that was automatically generating new activities was causing a crash as no action is returned when they are completed. This commit fixes this issue by handling the case where no action is returned. opw-2361674 Forward-Port-Of: odoo/odoo#60628
Original PR description
Before this commit, completing an activity that was automatically generating new activities was causing a crash as no action is returned when they are completed. This commit fixes this issue by handling the case where no action is returned. opw-2361674 Forward-Port-Of: odoo/odoo#60628
Before this commit, the badges' background color was not possible to edit: the previews were done correctly but the background color was removed after final selection. This was because the background color property is animated on badges, messing with the related edition function. Closes https://github.com/odoo/odoo/issues/59337 Forward-Port-Of: odoo/odoo#60717
Original PR description
Before this commit, the badges' background color was not possible to edit: the previews were done correctly but the background color was removed after final selection. This was because the background color property is animated on badges, messing with the related edition function. Closes https://github.com/odoo/odoo/issues/59337 Forward-Port-Of: odoo/odoo#60717
Zip cannot be required if not in format address. It will break ecommerce, because the customer cannot validate the adress because zip code is not displayed but required. Fix case in JS where field is not display to avoid traceback. This commit closes #58950 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-P
Original PR description
Zip cannot be required if not in format address. It will break ecommerce, because the customer cannot validate the adress because zip code is not displayed but required. Fix case in JS where field is not display to avoid traceback. This commit closes #58950 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#60694
If a merchants didn't enable a local Payment Method Type (PMT) on Stripe side (such as bancontact), his customers eligible for it (ex.: Belgian and paying in EUR) won't be able to pay using it. This commit fixes this issue by adding a condition on the payment icons assigned to Stripe: if the payment icon related to a given payment method is not listed as a supported payment icon, the related payment method is not offered to customers, unless the payment icon does not exist at all.
Original PR description
If a merchants didn't enable a local Payment Method Type (PMT) on Stripe side (such as bancontact), his customers eligible for it (ex.: Belgian and paying in EUR) won't be able to pay using it. This commit fixes this issue by adding a condition on the payment icons assigned to Stripe: if the payment icon related to a given payment method is not listed as a supported payment icon, the related payment method is not offered to customers, unless the payment icon does not exist at all. User can enable PMTs through (Payment Acquirers > Stripe > Configuration > Supported Payment Icons). This concerns: ideal, bancontact, eps, giropay and p24. This solution is not entirely satisfactory but it isn't possible to fetch enabled PMT from Stripe. Doc PR: odoo/documentation-user#774 opw-2335482 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60721 Forward-Port-Of: odoo/odoo#59836
It was hidden in https://github.com/odoo/odoo/commit/d1bbf11af27e4ce12b025ef22e397302ee6336c2 But customers actually need it. opw-2358111 Forward-Port-Of: odoo/odoo#60158
Original PR description
It was hidden in https://github.com/odoo/odoo/commit/d1bbf11af27e4ce12b025ef22e397302ee6336c2 But customers actually need it. opw-2358111 Forward-Port-Of: odoo/odoo#60158
TLDR: zero is not always zero in js STEPS: * On your POS, add a Cash rounding > Rounding precision 0.10 > Rounding method DOWN * Set a product with a Unit of Measure with 3 decimals (kg for instance) * In POS: - Make an order for 0.514 kg at 429.99€ + 0.510 kg at 429.99 + 0.60€ - The total of the order is 440.90 (exact total would be 440.90976) BEFORE: The total to pay is 440.80 AFTER: The total to pay is 440.90 WHY: * var total = round_pr(this.get_total_with_tax(),
Original PR description
TLDR: zero is not always zero in js STEPS: * On your POS, add a Cash rounding > Rounding precision 0.10 > Rounding method DOWN * Set a product with a Unit of Measure with 3 decimals (kg for instance) * In POS: - Make an order for 0.514 kg at 429.99€ + 0.510 kg at 429.99 + 0.60€ - The total of the order is 440.90 (exact total would be 440.90976) BEFORE: The total to pay is 440.80 AFTER: The total to pay is 440.90 WHY: * var total = round_pr(this.get_total_with_tax(), this.pos.cash_rounding[0].rounding); // 440.90000000000003 * var rounding_applied = total - this.get_total_with_tax(); // 5.684341886080802e-14 --- opw-2357917 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#60729 Forward-Port-Of: odoo/odoo#60642
Before this commit the layout of the website sale dashboard in community was broken because it contained nested h2 headers After this commit the layout of the website sale dashboard in community is back to normal Related to #26067 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#60737
Original PR description
Before this commit the layout of the website sale dashboard in community was broken because it contained nested h2 headers After this commit the layout of the website sale dashboard in community is back to normal Related to #26067 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#60737
It appears that the home menu props validation was too demanding: an app does not need to have an associated icon. Here we weaken the props validation so that, in debug mode, OWL won't complain anymore when it can't find an icon. Forward-Port-Of: odoo/enterprise#14374
Original PR description
It appears that the home menu props validation was too demanding: an app does not need to have an associated icon. Here we weaken the props validation so that, in debug mode, OWL won't complain anymore when it can't find an icon. Forward-Port-Of: odoo/enterprise#14374
Forward-Port-Of: odoo/enterprise#14333 Forward-Port-Of: odoo/enterprise#14160
Original PR description
Forward-Port-Of: odoo/enterprise#14333 Forward-Port-Of: odoo/enterprise#14160
Steps to reproduce the bug: - Go to a contact - Click on Partner Ledger - Click on Save - Choose a specific format to export your file - Set a specific file name N - Click on Export button Bug: The generated file had not the specific name N opw:2362391 Forward-Port-Of: odoo/enterprise#14317 Forward-Port-Of: odoo/enterprise#14242
Original PR description
Steps to reproduce the bug: - Go to a contact - Click on Partner Ledger - Click on Save - Choose a specific format to export your file - Set a specific file name N - Click on Export button Bug: The generated file had not the specific name N opw:2362391 Forward-Port-Of: odoo/enterprise#14317 Forward-Port-Of: odoo/enterprise#14242
This commit reverts a CSS rule applying globally a `margin-right` on ALL `o_dropdown_toggler_btn` elements once the `sale_subscription_dashboard` module is installed. This introduces an unnecessary margin for dropdown's buttons, breaking their layout on mobile-like screens. Reverting this rule as no information was provided in the original commit's message (see odoo/enterprise@50d854039bdef253ae50a95a828d816fdb7b5035) to properly scope it. Also, there is a similar rule in web's search
Original PR description
This commit reverts a CSS rule applying globally a `margin-right` on ALL `o_dropdown_toggler_btn` elements once the `sale_subscription_dashboard` module is installed. This introduces an unnecessary margin for dropdown's buttons, breaking their layout on mobile-like screens. Reverting this rule as no information was provided in the original commit's message (see odoo/enterprise@50d854039bdef253ae50a95a828d816fdb7b5035) to properly scope it. Also, there is a similar rule in web's search_view.scss file. Related task ID: 1879566 Forward-Port-Of: odoo/enterprise#14322
Forward-Port-Of: odoo/enterprise#14206
Original PR description
Forward-Port-Of: odoo/enterprise#14206
In the first line for the report number, the number we generate should have 347/349 in it. The sequence associated was only 10 long without the 347 or 349 included We also checked some other fields to see if they were number/string. Task: 2300236 Forward-Port-Of: odoo/enterprise#13461
Original PR description
In the first line for the report number, the number we generate should have 347/349 in it. The sequence associated was only 10 long without the 347 or 349 included We also checked some other fields to see if they were number/string. Task: 2300236 Forward-Port-Of: odoo/enterprise#13461
This commit fixes the default timezone assignation. Since 7e8d652b99c96cac1ffc63ae37257c419024031e, the returned timezone is directly the needed string and not an object anymore. Calling 'name()' on returned timezone is than not necessary anymore and leads to a crash. This commit simply remove the call to 'name()'. Task ID: 2333825 Forward-Port-Of: odoo/enterprise#14307
Original PR description
This commit fixes the default timezone assignation. Since 7e8d652b99c96cac1ffc63ae37257c419024031e, the returned timezone is directly the needed string and not an object anymore. Calling 'name()' on returned timezone is than not necessary anymore and leads to a crash. This commit simply remove the call to 'name()'. Task ID: 2333825 Forward-Port-Of: odoo/enterprise#14307
…taxcloud after carrier change Configure taxcloud, 2+ delivery carrier, card payment Go to the website shop Add product to cart Checkout with USA address On the Confirm Order page, the tax is computed via TaxCloud and shown on the right. Pay via payment acquirer site The Subtotal (without taxes) is sent to the Payment Acquirer instead of the Total This occur because when selecting delivery carrier coupon lines are recomputed. To be on the safe side with taxcloud, taxes are exclu
Original PR description
…taxcloud after carrier change Configure taxcloud, 2+ delivery carrier, card payment Go to the website shop Add product to cart Checkout with USA address On the Confirm Order page, the tax is computed via TaxCloud and shown on the right. Pay via payment acquirer site The Subtotal (without taxes) is sent to the Payment Acquirer instead of the Total This occur because when selecting delivery carrier coupon lines are recomputed. To be on the safe side with taxcloud, taxes are excluded before recomputing coupon lines, but never added in this specific flow. opw-2338103 opw-2362493 opw-2353048 Forward-Port-Of: odoo/enterprise#14337