Daily updates from Odoo
Tuesday, January 21, 2025
8 changes
2 changes
Resolved issues and error corrections
The Manufacturing barcode app now prevents users from adding unexpected products when the operation type does not allow extra products. This helps teams enforce manufacturing rules consistently and avoid incorrect materials being added to production orders.
Original PR description
Issue Before This Commit ======================== The barcode application for the 'Manufacturing' operation type allowed products to be scan and added to a Manufacturing Order (MO) even when the 'Allow Extra Product' setting was disabled. Steps to Produce ================= - Disable the 'Allow Extra Product' option for the 'Manufacturing' operation type. - Create a new MO or open an existing MO. - Scan a product other than the MO product still allowed it to be added, despite the setting being disabled. This commit removes the code that allowed extra products to be added, ensuring compliance with the operation type setting. Task: [4369998](https://www.odoo.com/odoo/my-tasks/4369998)
This fix restores access to the bank reconciliation screen for Invoicing, Banks, and Accounting Manager users. It adds the required permissions explicitly so eligible users can continue reconciling bank transactions without access errors.
Original PR description
The bank.rec.widget models are not stored and are primarily used for onchange computations The Invoicing and Banks user, and Manager user were somehow able to use the bank.rec.widget models until https://github.com/odoo/odoo/commit/74c5cd56a0539edab6a61efa517ca6a08c08d915 By granting access to the models with explicit security records, this issue is resolved. `group_account_user` implies `group_account_basic` Why did it work before? JS uses the bank.reco.widget model directly, see `fetch_initial_data` https://github.com/odoo/enterprise/blob/00d8bf44824858d322fbe05682f50ad3b53d07ff/account_accountant/static/src/components/bank_reconciliation/kanban.js#L578-L580 runbot-112206 runbot-112205
6 changes
Resolved issues and error corrections
Point of Sale preparation receipts now correctly show product variants that are configured to be created automatically. This helps kitchen or preparation staff see the exact item ordered and reduces fulfillment mistakes.
Original PR description
Product variant with creation type "always" would not be printer on the preparation receipt. Steps to reproduce: ------------------- * Create a product and add a variant with creation type "always" * Add a preparation printer to the point of sale * Create a new order and add the product with the variant * Validate the order and check the preparation receipt > Observation: the product variant is not printed on the receipt Why the fix: ------------ The product variant was not printed on the preparation receipt because the variant is added to the display name of the product and doesn't appear in the attribute list. This fix also add the first test for the preparation receipt. This should be improved in the future to cover more cases. opw-4450217
Manufacturing orders now correctly include and consume components that are added after the order has already been confirmed. This helps ensure production records, material usage, and inventory levels stay accurate throughout the manufacturing process.
Original PR description
With this PR : ------------------------------------------ - Addressed an issue where components added after MO confirmation were not being automatically consumed during production. - Implemented checks and updates in function to ensure all components are marked as picked before production. - This fix ensures that all components, including those added after MO confirmation, are properly accounted for and consumed during the production process. Task-id : 3951176
This fixes OAuth sign-in for new users on environments using newer software dependencies. Users will no longer see a misleading setup error, and authentication with external providers should work as expected.
Original PR description
Description of the issue/feature this PR addresses: The method `werkzeug.http.parse_www_authenticate_header` has been removed in werkzeug 3 and later. This causes an issue in Odoo when using python…
Description of the issue/feature this PR addresses: The method `werkzeug.http.parse_www_authenticate_header` has been removed in werkzeug 3 and later. This causes an issue in Odoo when using python 3.12, as the `requirements.txt` specifies werkzeug 3.0.1. This results in a misleading error stating that `auth_signup` is not installed on the database when authenticating a new user with an OAuth provider. Current behavior before PR: When attempting to authenticate a new user with an OAuth provider in Odoo using Python 3.12, the method werkzeug.http.parse_www_authenticate_header is called. Since this method is removed in Werkzeug 3.0.1, a misleading error message about auth_signup not being installed on the database is displayed. Desired behavior after PR is merged: The code will use WWWAuthenticate.from_header for parsing the WWW-Authenticate header if available, otherwise, it will fall back to using werkzeug.http.parse_www_authenticate_header for compatibility with older versions of Werkzeug (2.0 and 2.2). The misleading error message will no longer appear, and OAuth authentication will work as expected. Fixes #194002 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error that occurred after saving an image carousel on eLearning website pages. Carousel images and navigation buttons remain visible, helping editors publish course pages without broken galleries.
Original PR description
The image do not have the thumbails anymore 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
Refunded point-of-sale orders now send only positive amount values to Kenya's eTIMS tax system, as required. This prevents refund transactions from being rejected or reported incorrectly because of negative values.
Original PR description
When sending pos_order to eTims, all numeric values must be positive values, but when computing refunded pos_order, some fields are computed with negative value. This commit manage to transform negative fields from refunded pos_order to positive field. no-task
This update fixes an issue that could prevent scheduled Monster.com job board campaigns from starting correctly. It also adds regression tests to help ensure the Monster recruitment integration and its shared base logic keep working as expected in future updates.
Original PR description
This PR adds non regression tests for the integration of monster in hr_recruitment. These tests also cover at the same time the code of the hr_recruitment_integration_base module. The PR also fixes a bug in the hr_recruitment_integration_base module which was found thanks to the tests. The bugfix is about fixing variable names in the _start_new_campaign to match the fields of the module. task-4199469