Tuesday, December 1, 2020
30 changes · master
Enhancements to existing features
The IoT build process is updated to use Raspberry Pi OS 32-bit instead of the older Raspbian base. This helps keep Odoo's point of sale IoT image aligned with the current operating system platform for Raspberry Pi devices.
Original PR description
… IoT Change version of OS to build IoT From raspbian to raspberry pi os 32-bit 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
This update adds tools to generate realistic sample data for inventory, purchasing, manufacturing, products, suppliers, partners, and users. It helps teams test and demonstrate logistics workflows with richer, more representative data.
Original PR description
Populate for stock, purchase, mrp and supplier info
Accounting entries now keep the same tax tags users configured, even when tax amounts need their sign reversed for reporting. This reduces confusion in manual entries, cash-basis tax entries, and reconciliation write-offs while making tax report calculations more consistent.
Original PR description
The sign of tax tags sometimes could get inverted explicitly. It typically happened for misc operations, so :
- manual entries
- CABA entries
- writeoffs created from the reconciliation widget
We had to do things this way in stable to fix those use cases, but it's not ideal, as the tags shown to the user were inverted, so it was a bit confusing, as one would have expected to see the exact same tags as on tax configuration.
We fix that by using a boolean field on account.move.line telling whether or not the sign must be inverted. This allows keeping the same tags as in the tax config, and simplifies the computation of the tax report's multiplicator, making the overall model more intuitive for both user and developper.
Task 2363287Closing the website editor no longer leaves behind a browser warning when users try to leave the page. This removes an unnecessary interruption and makes the editing experience smoother.
Original PR description
Avoid having a warning pop-up after the wysiwyg editor is closed. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website visitor screens have been reorganized to make visitor data easier to read and analyze. Marketing users now see more relevant fields, clearer filters, multi-website context where applicable, and less technical clutter unless debug mode is enabled.
Original PR description
PURPOSE Make various changes to the website.visitor views to improve readability and ease marketing analysis. SPECS The changes include notably: - Add/rename/move fields/filters elements - Remove some unnecessary information or put it in optional="hide" in tree view - Add website_id information (with the multi-website group) - Slightly rework layouts (new widgets / spacing / images / buttons / ...) - Move some technical information into the "debug mode" LINKS Task 2092302 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
Inventory reservations can now be configured by operation type, letting businesses choose whether stock is reserved immediately, manually, or only near the scheduled date. This helps prevent future orders from taking stock needed for urgent work, while the old just-in-time procurement module is folded into sales inventory logic.
Original PR description
Currently stock moves are auto-assigned (i.e. reserve free stock) both when the scheduler is run and when a corresponding stock move that can assign a move is completed. This strictness was causing…
Currently stock moves are auto-assigned (i.e. reserve free stock) both when the scheduler is run and when a corresponding stock move that can assign a move is completed. This strictness was causing issues for prioritization of moves to assign, for example a picking with a scheduled_date far in the future could automatically reserve all stock if it was created before another picking that an immediate scheduled_date. To ease this, an extra setting has been added to stock.picking.type to let users choose how reservations should occur for moves assigned to that picking_type (or picking with that picking_type) when the move is already confirmed: 1. 'at_confirm' = automatically when new stock becomes available or when the scheduler is triggered. 2. 'manual' = user must always manually click "Check Availability" button (scheduler will no longer reserve). 3. 'by_date' = automatically when new stock becomes available or when the scheduler is run within the move's reservation_date. 'by_date' has an extra option of # days before the move's scheduled date that affects the move.reservation_date. Additionally, because this new feature overlaps with the `procurement_jit` module's functionality, we remove the module and ensure its logic is reproduced directly in `sale_stock`. Task: 2359317 Upgrade PR: odoo/upgrade#1868 ENT PR: odoo/enterprise#15050 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product ribbons in the website shop now show a readable label based on their HTML content instead of a generic technical record number. This makes back-office lists easier to understand and helps staff identify ribbons more quickly.
Original PR description
Model `product.ribbon` doesn't have 'name' field or '_rec_name' which displays record like `product.ribbon,1` in list. Now, we are using `html` field for display. Fixes #60204 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
Accounting entries now keep the same tax tags users see in tax settings, avoiding confusing reversed labels in cases like manual entries, cash basis entries, and reconciliation write-offs. This makes tax reports easier to understand and improves consistency between configuration and reporting.
Original PR description
The sign of tax tags sometimes could get inverted explicitly. It typically happened for misc operations, so :
- manual entries
- CABA entries
- writeoffs created from the reconciliation widget
We had to do things this way in stable to fix those use cases, but it's not ideal, as the tags shown to the user were inverted, so it was a bit confusing, as one would have expected to see the exact same tags as on tax configuration.
We fix that by using a boolean field on account.move.line telling whether or not the sign must be inverted. This allows keeping the same tags as in the tax config, and simplifies the computation of the tax report's multiplicator, making the overall model more intuitive for both user and developper.
Task 2363287Website visitor screens were updated to make visitor information easier to read and support marketing analysis. Push notification filters were also moved and renamed to better match the updated website layout.
Original PR description
PURPOSE Make various changes to the website.visitor views to improve readability and ease marketing analysis. SPECS Move and rename the push notification filters to follow new community layouts. LINKS Task 2092302
Resolved issues and error corrections
This update makes CRM lead conversion behave more consistently by preserving the original order of selected leads. It also adjusts sales test setup so internal automated checks run reliably without being affected by unrelated accounting permissions.
Miscellaneous changes
Before this commit, the messages explaining to the user why an input is readonly for VAT input in portal and VAT/company name inputs in e-commerce forms was untranslatable because t-att-title are not translated. This commit moves these messages into a t-set so that it could be translated. PR #51152 task-2369420 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 re
Original PR description
Before this commit, the messages explaining to the user why an input is readonly for VAT input in portal and VAT/company name inputs in e-commerce forms was untranslatable because t-att-title are not translated. This commit moves these messages into a t-set so that it could be translated. PR #51152 task-2369420 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#62509 Forward-Port-Of: odoo/odoo#60981
This fixes an issue where users could edit the copyright text in the website footer but their changes were not saved. The update ensures footer copyright customizations persist as expected, reducing confusion and repeated work.
Original PR description
The copyright part of the footer could be edited but not saved. Now it can be saved. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Help text on portal and online shop forms is now shown in a mobile-friendly way instead of relying on hover-only tooltips. The text can also be translated, making these forms clearer for customers in different languages.
Original PR description
This help text is invisible in mobiles, where you can't "hover" to see an input's `title`. Also it was impossible to translate due to the way it was written. Now it's usable and translatable. Uses a small help text as explained in https://getbootstrap.com/docs/4.1/components/forms/#overview @Tecnativa TT17694 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Help text in the portal and online shop is now shown in a mobile-friendly way instead of relying on hover behavior. This also makes the text available for translation, improving usability for customers in different languages and on smaller screens.
Original PR description
This help text is invisible in mobiles, where you can't "hover" to see an input's `title`. Also it was impossible to translate due to the way it was written. Now it's usable and translatable. Uses a small help text as explained in https://getbootstrap.com/docs/4.1/components/forms/#overview @Tecnativa TT17694 this commit closes #51152 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
Manufacturing work orders now calculate required non-tracked components correctly when producing more than originally planned, even if some components were already reserved. This helps avoid incorrect component consumption while keeping lot-tracked reservations tied to their specific lots.
Original PR description
The test from previously added feature allow a higher qty_producing than product_qty (i.e. originally planned) in a WO didn't properly consider non-zero reserved components. This change makes it so non-tracked components are correctly scaled to higher qty_producting amount, and also makes it so test does not expect lot tracked components to auto-scale when specific lot already reserved. Task: 2359317 COM PR: odoo/odoo#60300 Related Upgrade PR: odoo/upgrade#1868
The barcode app now handles unexpected packages and lot or serial numbers during batch picking without crashing or showing outdated information. This helps warehouse staff continue processing batches accurately when scanned items differ from what was originally expected.
Original PR description
These bugs are fixed in `stock_barcode` even if they happen when `stock_barcode_picking_batch` is installed, because the behavior of batch picking is very close to the picking one, but more restrictive. And so, it could create situations where the `stock_barcode_client_action` isn't prepared for.
opw-2394994 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#62655
Original PR description
opw-2394994 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#62655
Issue - Install "Calendar" and "Studio" modules - Go to Calendar app an open any event - Switch to Studio mode - Add a selection field X in the form then close Studio - Go to list view and try group by X Error message : "Grouping by X is not allowed." Cause `_get_public_fields` does not get custom fields created with studio. Solution Add custom fields to public fields. opw-2402667 Forward-Port-Of: odoo/odoo#62617
Original PR description
Issue - Install "Calendar" and "Studio" modules - Go to Calendar app an open any event - Switch to Studio mode - Add a selection field X in the form then close Studio - Go to list view and try group by X Error message : "Grouping by X is not allowed." Cause `_get_public_fields` does not get custom fields created with studio. Solution Add custom fields to public fields. opw-2402667 Forward-Port-Of: odoo/odoo#62617
Databases that already have issues are not able to fix the issues because it is impossible to reset the items to draft in order to change the date/sequence. Or do anything else, really. By allowing to bypass the constraint before a certain date, users can now edit problematic documents. Disabling the constraint will however make it possible to entirely break the sequences; use it with the lowest possible date. -- I confirm I have signed the CLA and read the PR guidelines at www.o
Original PR description
Databases that already have issues are not able to fix the issues because it is impossible to reset the items to draft in order to change the date/sequence. Or do anything else, really. By allowing to bypass the constraint before a certain date, users can now edit problematic documents. Disabling the constraint will however make it possible to entirely break the sequences; use it with the lowest possible date. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62486
Steps to reproduce the bug: - Create a BOM kit K with two components C1 and C2 Bug: It was possible to set an operation on K PS: Operation is not supported on BOM kit opw:2393302 Forward-Port-Of: odoo/odoo#62427
Original PR description
Steps to reproduce the bug: - Create a BOM kit K with two components C1 and C2 Bug: It was possible to set an operation on K PS: Operation is not supported on BOM kit opw:2393302 Forward-Port-Of: odoo/odoo#62427
The `name` field is not required on the `payment.icon` model. Therefore, in case the payment icon name is not set, a traceback is raised due to a `False.lower()` statement. opw-2409755 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#62632
Original PR description
The `name` field is not required on the `payment.icon` model. Therefore, in case the payment icon name is not set, a traceback is raised due to a `False.lower()` statement. opw-2409755 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#62632
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#57391
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#57391
- Activate Anglo-Saxon accounting - Set a foreign currency rate to 2.0 - Create a product A: Inventory Valuation: 'Automated' Costing Method: 'Standard Price' Cost: 10.0 Public Price: 100.0 - Create an invoice in foreign currency - Add 1 unit of A => the total amount is 200.0 - Confirm the invoice The Amount Due is 100.0 instead of 200.0. This happens because the Anglo-Saxon lines have the company currency, while the other lines have the foreign currency. Because of this,
Original PR description
- Activate Anglo-Saxon accounting - Set a foreign currency rate to 2.0 - Create a product A: Inventory Valuation: 'Automated' Costing Method: 'Standard Price' Cost: 10.0 Public Price: 100.0 - Create…
- Activate Anglo-Saxon accounting - Set a foreign currency rate to 2.0 - Create a product A: Inventory Valuation: 'Automated' Costing Method: 'Standard Price' Cost: 10.0 Public Price: 100.0 - Create an invoice in foreign currency - Add 1 unit of A => the total amount is 200.0 - Confirm the invoice The Amount Due is 100.0 instead of 200.0. This happens because the Anglo-Saxon lines have the company currency, while the other lines have the foreign currency. Because of this, the `_compute_amount` method considers the move as multi-currency to compute the various amount. However, the Anglo-Saxon lines should be neglected. This happens from 14.0 because all lines have a currency. In previous versions, lines in the company currency didn't have the `currency_id` set. opw-2390107 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#62543
Before this change, the apikeys' `_check_credentials` override would hard-check the `'interactive'` key. This turns out to be less than ideal for compatibility with older code which might not properly forward the environment (or might call `_check_credentials` from a non-override and pass in an empty env) as it straight crashes. Update the override to assume an interactive login if the information is missing (as that seems like the more secure option: it ignores apikeys and takes 2FA in accou
Original PR description
Before this change, the apikeys' `_check_credentials` override would hard-check the `'interactive'` key. This turns out to be less than ideal for compatibility with older code which might not properly forward the environment (or might call `_check_credentials` from a non-override and pass in an empty env) as it straight crashes. Update the override to assume an interactive login if the information is missing (as that seems like the more secure option: it ignores apikeys and takes 2FA in account if enabled). Also trigger a warning if the key was missing from the environment, such that the maintainer hopefully takes a look at the issue. Also allow a `user_agent_env` of `None`, this will also trigger the warning so seems OK. Forward-Port-Of: odoo/odoo#62664
Behavior prior to this commit: - if the tax eligibility is changed between the time the invoice created and the time it is posted, the invoice ends up with 2 tax lines: one for the "Tax Received" account and one for the "Cash Basis Transition" account - there was already code intended to remove such lines, at https://github.com/odoo/odoo/blob/36b7fbe75dc45cc98a698c4af610ee4a5114919e/addons/account/models/account_move.py#L642, but it was not hit when the `recompute_tax_base_amount` parameter
Original PR description
Behavior prior to this commit: - if the tax eligibility is changed between the time the invoice created and the time it is posted, the invoice ends up with 2 tax lines: one for the "Tax Received" account and one for the "Cash Basis Transition" account - there was already code intended to remove such lines, at https://github.com/odoo/odoo/blob/36b7fbe75dc45cc98a698c4af610ee4a5114919e/addons/account/models/account_move.py#L642, but it was not hit when the `recompute_tax_base_amount` parameter was true (something that was added in 226a1155124e890d00e33968feb43b9fd6b99fa5) Behavior after this commit: - only the tax line that is still applicable is kept on the invoice opw-2371745 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62674 Forward-Port-Of: odoo/odoo#62525
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#62656 Forward-Port-Of: odoo/odoo#62200
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#62656 Forward-Port-Of: odoo/odoo#62200
Due to Spanish fiscal positions tax mapping, this improvement includes in IRPF 7%, IRPF 15%, IRPF 18%, IRPF 19% and IRPF 20% both tax mapping (IVA Exento Repercutido & IVA Soportado exento) as it is in IRPF 1%, IRPF 2%, IRPF 9% and IRPF 21%. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60364
Original PR description
Due to Spanish fiscal positions tax mapping, this improvement includes in IRPF 7%, IRPF 15%, IRPF 18%, IRPF 19% and IRPF 20% both tax mapping (IVA Exento Repercutido & IVA Soportado exento) as it is in IRPF 1%, IRPF 2%, IRPF 9% and IRPF 21%. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60364
Move package usage on the right side of the form. Task : 2329116 Forward-Port-Of: odoo/enterprise#13560
Original PR description
Move package usage on the right side of the form. Task : 2329116 Forward-Port-Of: odoo/enterprise#13560
Documentation of LUX reports related to CoA: https://ecdf-developer.b2g.etat.lu/ecdf/secured/pcnMappingTables Accounts like 51% are not all active (balance sheet report field 197), some are passive too (balance sheet report field 357). Bank accounts like 5130% are not accepted by this CoA; so Odoo's default bank account 513001 must be remapped towards fields 197 or 357 depending on the balance. Accounts like 44113% should only fill in the line 167 and not the line 369. Additionally, allow
Original PR description
Documentation of LUX reports related to CoA: https://ecdf-developer.b2g.etat.lu/ecdf/secured/pcnMappingTables Accounts like 51% are not all active (balance sheet report field 197), some are passive too (balance sheet report field 357). Bank accounts like 5130% are not accepted by this CoA; so Odoo's default bank account 513001 must be remapped towards fields 197 or 357 depending on the balance. Accounts like 44113% should only fill in the line 167 and not the line 369. Additionally, allow filtering journals on Luxembourg's Balance Sheet(abr) and Profit&Loss(abr) reports to allow excluding some journals by default. Forward-Port-Of: odoo/enterprise#15018
Add an internal user [demo] having access to * Timesheet (onws timesheets) * planning (user) Create a Project with Visibility set to "invited internal users", add [demo] as allowed internal user Create a timesheet entry with that user on that project With [demo] try to adapt the timesheet you created The action is blocked by a record rule, even if the user is invited. opw-2394723 Forward-Port-Of: odoo/enterprise#15026
Original PR description
Add an internal user [demo] having access to * Timesheet (onws timesheets) * planning (user) Create a Project with Visibility set to "invited internal users", add [demo] as allowed internal user Create a timesheet entry with that user on that project With [demo] try to adapt the timesheet you created The action is blocked by a record rule, even if the user is invited. opw-2394723 Forward-Port-Of: odoo/enterprise#15026