Tuesday, July 23, 2024
12 changes
2 changes
Resolved issues and error corrections
Fixed an issue where turning off debug mode only hid the debug menu but left advanced settings, technical options, and extra user rights visible. This ensures debug-related features are fully disabled when requested and preserves page information when switching asset debugging options.
Original PR description
Before this commit, when debug mode was activated, and we wanted to deactivate (by the debug menu, the command pallet or the settings links), the debug mode wasn't completely and correctly…
Before this commit, when debug mode was activated, and we wanted to deactivate (by the debug menu, the command pallet or the settings links), the debug mode wasn't completely and correctly deactivated. The debug mode was removed from the URL and the debug menu wasn't accessible anymore, but not everything was deactivated. For instance : the settings were still there (Translations, Gamification Tools and Technical), the link tracker app is still visible, all the user technical rights and extra rights are still shown. The issue occurs, because we just remove it from the URL (to setting the debug to `undefined`); this will remove the debug menu, but won't deactivate correctly the debug mode. To deactivate correctly the debug mode, the debug should be set to `0`; Note that, this commit will also solve a minor issue, that when activate the assets debugging, or test assets debugging from the debug menu, the rest of the query string was lost. This could lead to some errors, when reloading do to lost information. opw-4042335 opw-4047116
This fixes sales orders showing negative delivered quantities when products are returned during the first step of a multi-step delivery flow. Businesses using two-step warehouse deliveries will now see accurate delivered amounts after partial or full returns, reducing confusion in order tracking and invoicing.
Original PR description
## Issue: - When multi-step delivery is enabled, validating then issuing a partial or full return on the first step (E.G. WH/Stock to WH/Output) results in negative values on the SO delivered…
## Issue: - When multi-step delivery is enabled, validating then issuing a partial or full return on the first step (E.G. WH/Stock to WH/Output) results in negative values on the SO delivered quantity field. ## Steps To Reproduce: - Enable multi-Step routes in settings. - Go to warehouses and on the main Warehouse set Outgoing Shipments to "Send goods in output and then deliver (2 steps)" - go to a product category and set up the 2 steps route on it. - create a SO and select a product with a quantity more than 1 from the category save then validate - the first delivery will appear (from WH/Stocl to WH/Output) - Validate it and then press return and either fill a partial or full return. - go back to the sales order page you will notice the the delivered quantity is negative of what was returned on the previous step which is wrong. ## Solution: - The strict mode in sale_stock's `_get_outgoing_incoming_moves` method only considers moves strictly delivered to customers. Despite calling this method with strict=True in `_compute_qty_delivered`, the issue persisted. - The problem was identified at the end of `_get_outgoing_incoming_moves`, where the method incorrectly accounts for returns. It checks that the return destination's usage is not "customer" but fails to verify if the source is "customer." - Added a condition to ensure that the source location's usage is "customer" for return moves. opw-3933009 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
10 changes
Resolved issues and error corrections
This fix corrects an issue in the Danish accounting reports where profit and loss figures from previous years were incorrectly being added to the current year's totals. The fix ensures that only the current fiscal year's profit and loss is included in the balance sheet calculations, preventing inflated financial figures when bill reversals occur.
Original PR description
Step to reproduce: 1. Install Accounting and l10n_dk 2. View the balance sheet in comparison to last year and check the current profit & loss 3. create a bill reversal for 2023 and confirm it 4. View the balance sheet and observe how the 2024 adds the 2023 total into its total Expected behavior: The PnL from the previous year should not be added to the total of that report line. Solution: Add the missing `date_scope` field on the formula to make sure it only considers the PnL from the start of the fiscal year, therefore getting the current year's PnL opw-3957488
Fixed a bug where signing items would disappear from the document when users dragged them outside the page boundaries. Previously, users had to refresh the page to see the item again. Now items remain visible and functional even when dragged out of bounds, improving the user experience during document signing.
Original PR description
Before this commit, after we drag a sign item out of bounds, it would disappear until we refresh the page. This was happening because we were hiding the item at drag start, then it would only get re-rendered after dropping it inside the page. Thus, if we dragged the item out of bounds instead of inside the page, the item would never get re-rendered. After this commit, the sign item can be dragged anywhere, even out-of-bounds. It works properly because now when the item is dragged out-of-bounds, we make the item visible again even though the the invalid operation is discarded. task-4037888
This fix resolves an issue where the invoicing quantity calculation was failing when the Stock module was not installed. The system now properly confirms sales orders in the Field Service workflow when Stock is unavailable, ensuring that invoicing amounts are calculated correctly instead of defaulting to zero.
Original PR description
When stock is not installed, the override of _fsm_ensure_sale_order in industry_fsm_stock doesn't auto-confirm sale order, so the test `test_qty_to_invoice_from_fsm` failed because the `qty_to_invoice` was set to 0 if the order was not confirmed. With this PR, the order is confirmed in the test flow if stock is not installed. opw-[4061485](https://www.odoo.com/web#id=4061485&view_type=form&model=project.task)
This fix corrects an issue where period numbers in the Dutch XAF (eXtensible Audit File) export were showing incorrect values (401-412) instead of the correct monthly periods (01-12). This ensures that financial reports exported for compliance purposes display accurate period information.
Original PR description
Steps: - Install l10n_nl_reports - Open GL for the year 2024 - Export XAF -> Period numbers are displayed from 401 to 412, instead of 01 to 12 in the exported file opw-3999985 Forward-Port-Of: odoo/enterprise#67127 Forward-Port-Of: odoo/enterprise#67098
This fix corrects an issue where the salesperson field on field service sales orders was not being properly populated. Previously, the system would incorrectly clear the salesperson even when no task assignee existed. Now it correctly sets the salesperson to the first assigned team member on the task, or the current user if no one is assigned.
Original PR description
Steps to reproduce: - Projects > Field Service > New - Pick a customer but no assignee - Products > Add any product - Back to task > Sale order > Other info tab What happens: No salesperson is set. Expected behavior: salesperson is the first assignee on the task if any, current user if not (first assignee as in the first listed on the task, which sorts them alphabetically). opw-4026074 opw-4015184 (duplicate)
Fixed permission issues that prevented accountants without admin rights from setting up passwords for Dutch tax reporting (SBR). Accountants can now configure the password through a wizard when needed, and once set correctly, the system won't ask for it again, improving the user experience for non-admin accounting staff.
Original PR description
…ights The setup of the password from a related field would throw errors to user with accountant rights but no administration (settings) rights. This showed other access rights problems with the SBR implementation. The way we want to work with this is: an accountant without settings rights can set up the password through the wizard if no password is stored on the company (for databases that didn't start SBR with the status info module). Once the password is set and is correct (it is the right one for the certificate), it shouldn't ask the user to put it again and is thus hidden in the wizard. ticket-4024344 Forward-Port-Of: odoo/enterprise#66096
This update corrects how self-withholding taxes are handled in Colombian electronic invoicing. Previously, certain taxes were correctly excluded from the XML report but were still being counted in the total amounts, causing discrepancies. Now these taxes are properly excluded from both the report and the totals, ensuring accurate financial reporting.
Original PR description
Previously, we added support for self-withholding taxes, which do not need to be reported in the XML file. Hence, tax lines that contain a tax with a code ZZ (for customer invoices)/ ZZ, 07 (for vendor bills) are filtered out. However, when we compute the total amounts these are not filtered out, leading to a discrepancy in sums. We should filter out such tax lines when computing totals as well. See other commit: https://github.com/odoo/enterprise/commit/af8f364cc1f09cc1f9159b326a7f59c6524380be opw-3958518 Forward-Port-Of: odoo/enterprise#67012 Forward-Port-Of: odoo/enterprise#66918
This fix resolves an issue where the last letter of project and task names was being cut off in the timesheet grid view when displayed in italic font. The solution adds extra spacing to accommodate italic text, ensuring all text is fully visible without truncation.
Original PR description
- 17.0 We reverted the commit https://github.com/odoo/enterprise/commit/a789702766df289f4abe993374583a69027ef572 because it was causing the issue of hiding days when the row name was too long in the timesheet grid view. ### Steps to reproduce: - Install the project and timesheet app. - Open the project app, create a project, and add a task to it. - Add a timesheet a week before the current date for the created task. - Now open the timesheet app in grid view. - The created project and task are in italic font. - The last letter of the project and task name is slightly cut. ### Issue: The last letter of the string is slightly cut in the timesheet grid view. ### Cause: The dedicated space allowed for normal text is not sufficient for the italic. So, the last letter was slightly cut. ### Solution: Provide an extra space to the italic string. task-3888277
This update adjusts how the Kenya EDI system logs messages when no company information is found during routine scheduled tasks. Instead of flagging these occurrences as errors, they are now logged as warnings, which better reflects that this is a normal operational situation rather than a system problem. This reduces unnecessary alert notifications and helps teams focus on actual issues.
Original PR description
Currently, log level error message occur when no company is found during scheduled actions run at line [1]. This commit changes 'logger.error' to 'logger.warning' to log a message instead of an error since this is not an actual error in the code base. [1]-https://github.com/odoo/enterprise/blob/ddc81ed35a6738739647db868c13236673695cff/l10n_ke_edi_oscu/models/res_company.py#L437-L438 sentry-5608113473
This fix corrects an issue in the Sales Planning app where shifts created from the "Open Shifts" section were not being assigned to the resource selected by the user. Now when users create a shift by clicking on a cell and selecting a resource, the shift is properly created with the correct resource, date, and other parameters they specified.
Original PR description
Steps to Reproduce: ----------- - Install sale planning. - Create a sale order with a plan product. - Navigate to the Planning app > Schedule > By Resource. - Click on a cell in the "Open Shifts" line. - Select a resource. - Save and close. - Check the shift resource. Issue: ---------- The shift is not being created in the open shift section based on the parameters selected by the user. Fix: ---------- When creating a shift from the open shift section, it should generate shifts according to the parameters selected by the user, such as resource, date, etc. task-3919549