Monday, September 9, 2024
10 changes · saas-17.1
Resolved issues and error corrections
This update prevents an error from appearing when opening Accounting settings for Mexican localization in certain database replica setups. It adjusts when the settings view is changed so users can access the page reliably without triggering a read-only failure.
Original PR description
To reproduce: - Launch Odoo instance with the option --db_replica_host='' - Install l10n_mx - access Settings > Accounting - You'll get the error in the log The Issue During testing, attempting to modify a field's state using the 'get_views' function, which is marked as read-only, results in a read-only error. The Fix: To resolve this, apply changes only when we are not in test mode and ensure the view is initially imported as inactive. runbot-60422
Demo employee records in Sale Timesheet now get their own dedicated customer contacts instead of being linked to incorrect existing contacts. Related loyalty point-of-sale tests were adjusted so test customers continue to appear correctly after the demo data change.
Original PR description
The employees created in the demo data (see https://github.com/odoo/odoo/pull/108795) of sale_timesheet were linked to the wrong partners, we then create new partners dedicated to those new employees. version-17.1 task-3874828 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A basic automated check was added for the UAE payroll module to confirm payslips can be created without errors. This helps reduce the risk of payroll rule issues going unnoticed in future updates.
Original PR description
Before this commit, no test were set in that l10n. This commit adds a very basic configuration for tests and creates a payslip to ensure that no rule create a traceback.
Miscellaneous changes
Issue addressed by this commit: An ambiguous column error occurs in the hr_holidays model when the auth_signup module is installed alongside it, due to both modules having a state field. This ambiguity arises within the _get_on_leave_ids method, affecting the execution of a SQL query designed to identify users on leave. How to reproduce the issue: Install both hr_holidays and auth_signup modules. Attempt to execute the _get_on_leave_ids method to identify users on leave. Behaviour befor
Original PR description
Issue addressed by this commit: An ambiguous column error occurs in the hr_holidays model when the auth_signup module is installed alongside it, due to both modules having a state field. This…
Issue addressed by this commit: An ambiguous column error occurs in the hr_holidays model when the auth_signup module is installed alongside it, due to both modules having a state field. This ambiguity arises within the _get_on_leave_ids method, affecting the execution of a SQL query designed to identify users on leave. How to reproduce the issue: Install both hr_holidays and auth_signup modules. Attempt to execute the _get_on_leave_ids method to identify users on leave. Behaviour before this commit: An "ambiguous column error" is raised due to the SQL query not specifying which state field to use, leading to confusion between the state fields in the hr_leave and res_users tables. Expected behaviour: The SQL query should clearly reference the state field from the hr_leave table, avoiding ambiguity and accurately identifying users on leave without errors. Solution: The SQL query within the _get_on_leave_ids method has been updated to use hr_leave.state = 'validate' for clear distinction, resolving the ambiguous column error. opw-3770758 Forward-Port-Of: odoo/odoo#156663
### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a backorder - Create a product P (no need for a bom) - Create and confirm a manufacturing order for 2 units of the product - Go to the barcode module > operations > manufacturing > the MO - Register only one unit of P and produce #### > A backorder is automatically created but you are redirected to t
Original PR description
### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a…
### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a backorder - Create a product P (no need for a bom) - Create and confirm a manufacturing order for 2 units of the product - Go to the barcode module > operations > manufacturing > the MO - Register only one unit of P and produce #### > A backorder is automatically created but you are redirected to the backend. #### Note: If you were in "ask" on create backorder or if your product had a bom and you did not register the quantities of consumed components, a pop up would appear and resolving the pop up would redirect you to the kanban view of mrp.production in the barcode module. ### Cause of the issue: The issue was originally solved by commit d90acab by overriding the `action_backorder` however, since commit 1e5c82f the action_backorder is no more part of the flow in "always" backorder. opw-3890886 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178492
Steps to reproduce: ------------------- - Have xlrd >= 2.0 and openpyxl 3.1.2 - Using the `base_import` module, import an XLSX file with dates - Test -> ValueError unconverted data remains: 00:00:00 Cause: ----- Since xlrd 2.0.0 in (#169245), if we have a date in an XLSX file, we nonetheless always get a datetime with a time value of 00:00:00 instead of a date object. This datetime later fails to be converted to a date because of an "unconverted data remains: 00:00:00" error. Fix:
Original PR description
Steps to reproduce: ------------------- - Have xlrd >= 2.0 and openpyxl 3.1.2 - Using the `base_import` module, import an XLSX file with dates - Test -> ValueError unconverted data remains: 00:00:00 Cause: ----- Since xlrd 2.0.0 in (#169245), if we have a date in an XLSX file, we nonetheless always get a datetime with a time value of 00:00:00 instead of a date object. This datetime later fails to be converted to a date because of an "unconverted data remains: 00:00:00" error. Fix: --- Use is_datetime() from openpyxl.styles.numbers to check cell.number_format instead of depending on object type. Forward-Port-Of: odoo/odoo#177782
### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a backorder - Create a product P (no need for a bom) - Create and confirm a manufacturing order for 2 units of the product - Go to the barcode module > operations > manufacturing > the MO - Register only one unit of P and produce #### > A backorder is automatically created but you are redirected to t
Original PR description
### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a…
### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a backorder - Create a product P (no need for a bom) - Create and confirm a manufacturing order for 2 units of the product - Go to the barcode module > operations > manufacturing > the MO - Register only one unit of P and produce #### > A backorder is automatically created but you are redirected to the backend. ### Note: If you were in "ask" on create backorder or if your product had a bom and you did not register the quantities of consumed components, a pop up would appear and resolving the pop up would redirect you to the kanban view of mrp.production in the barcode module. ### Cause of the issue: The issue was originally solved by commit d90acab by overriding the `action_backorder` however, since commit 1e5c82f the action_backorder is no more part of the flow in "always" flows. opw-3890886 Forward-Port-Of: odoo/enterprise#69169
### Steps to reproduce: - Enable packages in the inventory settings - Create a storable product tracked by Lot and put 4 units in stock: - 2 Units for "LOT001" - 2 Units for "LOT002" - Create and confirm a sale order for 2 units - Go to the barcode app > Operations > Delivery orders > your Delivery Order - Register "LOT002" manually > One unit will be added to your delivery moves. - Put in pack > You can unroll the move to see that one move line was created for 1 unit with a package a
Original PR description
### Steps to reproduce: - Enable packages in the inventory settings - Create a storable product tracked by Lot and put 4 units in stock: - 2 Units for "LOT001" - 2 Units for "LOT002" - Create and…
### Steps to reproduce: - Enable packages in the inventory settings - Create a storable product tracked by Lot and put 4 units in stock: - 2 Units for "LOT001" - 2 Units for "LOT002" - Create and confirm a sale order for 2 units - Go to the barcode app > Operations > Delivery orders > your Delivery Order - Register "LOT002" manually > One unit will be added to your delivery moves. - Put in pack > You can unroll the move to see that one move line was created for 1 unit with a package and 1 unit is still missing. - Register a second unit of "LOT002" manually to put in an other pack > The line is updated to 2 units instead of 1 so that the additional unit can not be packed in an other pack ### Expected behavior: You should be able to pack units of the same lot in different packages. ### Cause of the issue: To determine which line is going to be updated by our lot registration the `_findLine` method is called. This method look for each line in pageLines and when it finds a candidate move line it continues to find a better candidate. However, fully packed moves should not be considered as valid candidates. opw-4068334 Forward-Port-Of: odoo/enterprise#68814 Forward-Port-Of: odoo/enterprise#68535
* With an IN company setup * Open the bank Reconciliation widget * Make a manual reconciliation with tax 18% IGST RC * Go to tax report GSTR-3B * Issue: there is no impact on the report (3.1 d) This occurs because in the report we take into account move of type `out_invoice` while move registered in the bank journal are of type `entry` Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4058256) opw-4058256 Forward-Port-Of: odoo/enterprise#67520
Original PR description
* With an IN company setup * Open the bank Reconciliation widget * Make a manual reconciliation with tax 18% IGST RC * Go to tax report GSTR-3B * Issue: there is no impact on the report (3.1 d) This occurs because in the report we take into account move of type `out_invoice` while move registered in the bank journal are of type `entry` Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4058256) opw-4058256 Forward-Port-Of: odoo/enterprise#67520
Versions: ----------- 15.0 Steps to Reproduce -------------- - Install industry_fsm_sale - Create a new user with these access rights. Project -> user Field Service -> user Timesheets -> User: own timesheets only - Create a new task, and assign it to the created user. - Login as user - Open the task Issue ---------- - The 'New quotation' button is visible even user has no sales access rights. Cause --------- - The user is getting access to the button from the field service g
Original PR description
Versions: ----------- 15.0 Steps to Reproduce -------------- - Install industry_fsm_sale - Create a new user with these access rights. Project -> user Field Service -> user Timesheets -> User: own timesheets only - Create a new task, and assign it to the created user. - Login as user - Open the task Issue ---------- - The 'New quotation' button is visible even user has no sales access rights. Cause --------- - The user is getting access to the button from the field service group. Fix --------- - We remove the group from the button. - We only show 'New Quotation' button if user have sales access rights. task-3827319 Forward-Port-Of: odoo/enterprise#69461 Forward-Port-Of: odoo/enterprise#60536