Tuesday, December 5, 2023
13 changes · 17.0
Resolved issues and error corrections
Fixed an issue in Web Studio where selecting a non-existent method when creating a custom button would cause a confusing error. Now, the system provides a clear validation error message when users try to use a method that doesn't exist in the model, making it easier to identify and correct the mistake.
Original PR description
The customer wants to use Web Studio to create an add custom button from an existing method in the model; however, there is a non-existent method identified, at that time the error will be generated.…
The customer wants to use Web Studio to create an add custom button from an existing method in the model; however, there is a non-existent method identified, at that time the error will be generated.
step to reproduce:
- install the `web_studio & sale_management`
- open sale
- open any one Quotations
- click on `web_studio` button
- click on Add button
- enter the label & select `call a method`
- write method name `action_delete` (non-existing method in model)
- the error will be generated,
sentry traceback-
```
AttributeError: 'sale.order' object has no attribute 'prin'
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1960, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "home/odoo/src/enterprise/17.0/web_studio/controllers/main.py", line 1697, in check_method
if not callable(getattr(model, method_name)):
```
after this commit ,If the customer prefers a non-existing method,at that time raise Validation Error.
sentry-4614276017This fix corrects the Tax Report for Argentine companies to display the invoice date (Bill Date) instead of the accounting date in the Date column. Previously, when an invoice had a different accounting date than its bill date, the report would show the wrong date, causing confusion in tax reporting and compliance documentation.
Original PR description
Task Adhoc: 32101 Task latam: 1121 #### Steps to reproduce: 1. Go to runbot Odoo 16 enterprise and install "l10n_ar_edi" module (Argentinean Electronic Invoicing). 2. Take position on Argentinian…
Task Adhoc: 32101 Task latam: 1121 #### Steps to reproduce: 1. Go to runbot Odoo 16 enterprise and install "l10n_ar_edi" module (Argentinean Electronic Invoicing). 2. Take position on Argentinian company (AR) (Responsable Inscripto). 3. Create a vendor bill with a journal that use documents and with "Accounting Date" one month after the "Bill Date". For example: "Bill Date" = "09/22/2023" and "Accounting Date" = "10/01/2023". Finally confirm the invoice. 4. Go to "Accounting / Reporting / Statement Reports / Tax Report", select "Tax Type: Purchases" and filter by the same month of the "Accounting Date" mentioned in step 3 (in this case: October). 5. The column "Date" must show "Bill Date" instead of "Accounting Date" for each document. #### Current behavior: "Tax Report" with "Tax Type: Purchases" is showing on column "Date" the value of the "Accounting Date" instead of "Bill Date". #### Expected behavior: "Tax Report" with "Tax Type: Purchases" is showing on column "Date" the value of of "Bill Date". Forward-Port-Of: odoo/enterprise#50774
This update addresses compliance requirements for Belgian POS systems in version 17. The fix resolves issues with product deletion functionality, enables proper cash rounding settings, and removes commented-out validation checks to ensure the system meets certification standards.
Original PR description
In order to be certified, few changes has to be done in v17. We fix deletion of the product that was not working. The cash rounding was not set. the check was commented and we remove the comment.
This update fixes three critical issues when copying spreadsheet history: the snapshot data was not being preserved during the copy process, active revision history was incorrectly carried over to the copied spreadsheet, and the snapshot was referencing the wrong revision ID. These fixes ensure that when users copy a spreadsheet's history, the data is accurately preserved and the revision tracking works correctly.
This fix enables users to remove previously set values from optional settings in Web Studio, such as image sizes, allowing them to revert to default behavior. Previously, once a value was set, it couldn't be removed from the view. The change includes a test to verify the remove functionality works correctly.
Original PR description
This commit allows the value of an option to be unset. Before this commit, once a value had been set, it was impossible to remove it from the view. For example, an image size couldn't be unset to keep the default behavior. A test has been added to verify that the SelectMenu has a remove button, and that the value can be remove effectively. task-3470048 Forward-Port-Of: odoo/enterprise#51646 Forward-Port-Of: odoo/enterprise#47400
This fix resolves two critical issues in the Shop Floor workorder process. Previously, clicking 'Mark as Done' would fade out the workorder without validating required information like lot/serial numbers for the final product, and there was no way to close production on the last workorder. Now the system properly validates all prerequisites before allowing workorders to be marked complete.
Original PR description
In the Shop Floor, on a workorder, 'Mark as Done' do not check for its prerequisites before fading out, giving you for example no chance to fill the missing lot/serial for the final product. Moveover, on the last workorder, you have no way to 'Close Production'.
This update corrects the Balance Sheet and Profit & Loss reports for Kazakhstan operations to align with official financial statement requirements. The changes ensure disposal group assets and liabilities are properly included in totals, equity accounts display with correct signs, and expense/income lines show accurate values based on debit/credit conventions. These corrections ensure financial reports are balanced and compliant with Kazakhstan accounting standards.
Original PR description
Balance Sheet: - Lines 101. Assets (or disposal groups) held for sale, and 301. Liabilities of disposal groups held for sale should be added to the totals of Assets and Liabilities, respectively. - The sign of account 51 should be + not - since it's an Equity account. Profit & Loss: - I've changed the sign of the accounts used for each report line, so that lines that expect to be expenses are positive on debit, and lines that expect to be income are positive on credit. Source: official financial statements, found at https://adilet.zan.kz/rus/docs/V1700015384 This is part of the wider task of re-balancing the Balance Sheets. I've checked that with these changes, the Balance Sheet is always balanced. (Checked using the TestBalanceSheetBalanced test from https://github.com/odoo/enterprise/pull/47602) taskid:3060790 Forward-Port-Of: odoo/enterprise#47604
This fix resolves an issue where WhatsApp guest users were experiencing unnecessary message separators and repeated server calls when loading public pages. The system now properly tracks when guests have viewed messages, reducing redundant processing and improving the user experience for guest visitors.
Original PR description
Since 17.0, the new message separator is displayed for guests. The set_last_seen_message rpc is also triggered in order to save this information on the server side. However, the _channel_seen method does not handle guests as it should. As a consequence, the new message separator is always displayed and the rpc call is always done when a guest loads the public page. This PR enable guest support for this feature. task-3603603 community: https://github.com/odoo/odoo/pull/142546
Employees with flexible work hours can now have their schedules properly displayed in the Planning app. Previously, when an employee's working hours were left blank (as required for flexible scheduling), their published schedules would fail to display. This fix allows the system to correctly handle flexible hour employees by skipping unnecessary time calculations.
Original PR description
Issue Description: ================== An employee is configured for flexible work hours. However, when their schedule is planned, it fails to display correctly. In Odoo 16.3, to establish flexible…
Issue Description: ================== An employee is configured for flexible work hours. However, when their schedule is planned, it fails to display correctly. In Odoo 16.3, to establish flexible hours, one must select `planning` in the employee's contract. Consequently, the `Working hours` field (found under `Schedule` in the `Work Information` tab) should be left blank. Intriguingly, if `Working hours` are reinstated in `Work Information,` the planning becomes visible, but this action contradicts the flexible hours setting. Steps to Reproduce: =================== 1. Navigate to the `Employees` app and select an employee. 2. Access the `Work Information` tab and clear the `Working hours` field. 3. Go to the `Planning` app, and publish a schedule for the selected employee. 4. Switch to developer mode and proceed to `Settings` > `Technical` > `Email` > `Emails`. 5. Attempt to open a link from the relevant email; the planning will not be displayed. Proposed Solution: ================== Modify the process so that when an employee's `Working Hours` are not set, the system bypasses the calculation of 'minTime' and 'maxTime' values in the 'timeGridDay' and 'timeGridWeek' components. This should allow for the correct display of planning schedules for employees with flexible working hours. opw-3608860 Forward-Port-Of: odoo/enterprise#51943
Users encountered an access error when trying to update hours in the timesheet grid for tasks assigned to them in private projects they don't follow. This fix allows the system to properly verify project settings without requiring direct access to the project record, enabling employees to log time on their assigned tasks regardless of project visibility settings.
Original PR description
Versions: --------- -16.3e+ Steps to reproduce: ------------------- - Have a private project you don't follow with a task assigned to you; - go to timesheets; - add a line with the task; - update hours via the grid. Issue: ------ Access error, you don't have access to `project.project` record. Cause: ------ odoo/odoo#133443 added the ability for users to search & add tasks assigned to them from private projects to the Timesheets grid. That issue was caused by checking the `allow_timesheets` field of a project they don't have access to. Similarly, the`grid_update_cell` method also double checks that the record you're updating has `allow_timesheets` enabled, leading to the access error when the task belongs to a project you cannot access. Solution: --------- Use `sudo` before trying to access `project_id.allow_timesheets`. Also fixed a warning in kanban view caused by comparing a record with a record id. opw-3587411 Forward-Port-Of: odoo/enterprise#51976
This fix resolves an issue where Mexican invoices with MXN currency were failing CFDI validation because the USD amount was incorrectly calculated as zero. The system now properly computes the MXN to USD exchange ratio needed for external trade invoices, allowing them to pass validation successfully.
Original PR description
With an MX company setup Create an invoice Add foreign partner Set fields Incoterm and External trade Set currency to MXN Add a line Confirm Send&Print CFDI Validation will fail with error Code : CCE173 Message : El valor del atributo cce11:ComercioExterior:Mercancias:Mercancia:UnidadAduana es igual a "99"o el atributo cce11:ComercioExterior:Mercancias:Mercancia:ValorUnitarioAduana es igual a cero. In the CFDI the amount in USD of the move is reported as 0. This occurs because, when the main currency is MXN, we don't have `tipo_cambio` in cfdi values, but we need the amount to compute the ratio to USD opw-3601134 Forward-Port-Of: odoo/enterprise#52066
This fix prevents users from accidentally converting a regular sales order into a subscription order after it has been confirmed. Previously, the recurrence and plan fields remained editable even on confirmed orders without subscription products, which could lead to unintended changes. Now these fields are automatically hidden when a confirmed order doesn't contain subscription products.
Original PR description
…firmed Currently, if you create a SO without subscription products and confirm it, the recurrence field will still be editable. Therefore allowing to change a confirmed SO to a subscription. This is an undesired behavior and should not be possible. This commit fixes that by hiding the recurrence field in confirmed SO without subscription products. task-3600687 Forward-Port-Of: odoo/enterprise#50860
This fix corrects an issue where refund work days in payroll were incorrectly being marked as half-days. The problem occurred because the system wasn't properly accounting for negative day values that occur during refunds. This ensures accurate payroll calculations and reporting for refunded work periods.
Original PR description
Change fixes problem with every refund work day being labeled as half-day. It was caused by the fact that number_of_days is negative in case of refund and function checking whether work day is half didn't take it into account. task-3523846 Forward-Port-Of: odoo/enterprise#51981 Forward-Port-Of: odoo/enterprise#49568