Daily updates from Odoo
Monday, September 23, 2024
8 changes
1 change
Resolved issues and error corrections
The Time Off dashboard calendar now stays correctly arranged when users toggle the “Show Weekends” option in yearly view. The dashboard also correctly respects the weekend visibility setting after a page refresh, reducing confusion for employees and HR teams reviewing leave schedules.
Original PR description
Before this commit when the filter on the Time Off Dashboard is set to "Year" (which is default) and the "Show Weekends" filter is toggled, the entire calendar view of the dashboard becomes…
Before this commit when the filter on the Time Off Dashboard is set to "Year" (which is default) and the "Show Weekends" filter is toggled, the entire calendar view of the dashboard becomes scrambled. It returns to its normal state when the page is refreshed. Also when "Show Weekends" filter is in false state and we refresh the page we are getting weekends in calendar view of dashboard while the "Show Weekends" filter state remains false. Steps to reproduce : - Go to Time Off Module - Click on scale selector and then click on "Show Weekends" filter - The entire calendar view of the dashboard becomes scrambled After this commit the calendar view of time off dashboard will not be scrambled when we toggle the "Show Weekends" filter. Also we will get weekdays in calendar view of dashboard when "Show Weekends" filter is in false state and we refresh the page. Task-4072516 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
3 changes
Resolved issues and error corrections
Fixes an issue where quotation calculators could fail or load the wrong sales order lines when synced fields targeted positions above the first line. Saving from the spreadsheet is now more reliable and avoids unnecessary reloading when all line positions are already available.
Fixed an issue in the Barcode app where scanning a non-GS1 product barcode together with multiple serial numbers could cause an error when GS1 nomenclature was enabled. This helps warehouse users continue receipt operations smoothly and prevents stuck scan counts on screen after failed parsing.
Original PR description
How to reproduce ================ - Create a product tracked by SN and set a barcode (ex.: productserial1) - Select the Default GS1 Nomenclature in the Inventory Settings - Open the Barcode App > Operations > Receipts > New - Scan a barcode containing the created product's barcode and multiple serial numbers (eg.: 'productserial1,sn1,sn2,sn3,sn4') --> Traceback. Cause of the issue ================== There is two issues: 1. The parser throws an error if it tries to parse a barcode with the GS1 nomenclature and fails and this error wasn't handle bv the BarcodeObject when it parses its barcode. 2. If the BarcodeObject wasn't parsed and has no missing record, it wasn't processed and the barcode's count stay on the screen.
Resource-based appointments booked online now show correctly in the Gantt planning view. This prevents missed bookings in operational schedules by removing an inappropriate privacy check for events that are tied to resources rather than individual users.
Original PR description
Purpose ======= Fix the resource events which weren't displayed in the gantt view when booked from the front-end. Specification ============= When an appointment based on resources is booked from the front-end, the event "user_id" field is set to be OdooBot. This is an issue as the read_group domain for the calendar.event model checks the user_id 'res_users_settings_id' field for privacy purpose but OdooBot doesn't have any users settings. => The read_group domain is always evaluated to False. No resource based events booked from the front-end are displayed on the gantt view. Fixing that by updating the privacy domain to be sure every events related to a resource can now be visible and accessible on the gantt view. The privacy field of an event is mainly related to the user settings but resource events aren't typically linked to any user meaning their visibility shouldn't depend on the privacy. Task-4191434
4 changes
Resolved issues and error corrections
Fixed an issue where CFDI documents were not being saved when validation errors occurred during invoice processing in Mexico. Users can now view failed documents in the CFDI tab to check error details and retry the operation, improving the error recovery experience for Mexican invoicing.
Original PR description
**Steps to reproduce:** - Install l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice with an invoice date from one month ago - Confirm the invoice - Generate CFDI via "Send & Print" button - A validation error should be raised **Issue:** No document is available in CFDI tab to check the error or retry. **Cause:** A fix had been made to commit the document in case of success, but it had removed the commit in case of failure. https://github.com/odoo/enterprise/commit/fed4ea40793e5d835f3bf7c0267526bd32075baf opw-4203720
This fix corrects the titles that appear for resource appointment events when syncing to calendars and exporting to ICS files. Previously, these titles were showing irrelevant information due to custom appointment titles overriding the correct event names. This ensures users see accurate appointment details in their calendar applications.
Original PR description
The titles in calendar sync and ICS files were irrelevant for resource appointment events because of the custom titles created for appointments. This PR fixes the issue of incorrect titles in calendar sync and ICS files. Task-3919395
This fix corrects an issue where invoices with certain intra-community taxes were being counted twice in the EC Sales Report for Austrian companies. The system was applying multiple tax tags to the same invoice line, causing duplicate amounts in the report. The fix ensures each invoice is counted only once by adjusting which tax tag is used for reporting.
Original PR description
### Issue Invoices using consumable intra-community taxes are currently counted twice in the EC Sales Report. ### Steps to Reproduce 1. Install `l10n_at_reports`. 2. Switch to an Austrian company. 3.…
### Issue Invoices using consumable intra-community taxes are currently counted twice in the EC Sales Report. ### Steps to Reproduce 1. Install `l10n_at_reports`. 2. Switch to an Austrian company. 3. Create and post an invoice using a consumable intra-community tax (e.g., 'UST_017 IGL 0% (ohne Art. 6 Abs. 1)'). 4. Open the EC Sales Report. You will observe that the invoice amount is counted twice. ### Cause The system groups values in the EC Sales Report by tax tags. A previous commit (odoo/odoo@f937e915dfd64a9b66dd9f7d7e3d19607d088f28) introduced changes to certain taxes (e.g., 'UST_017 IGL 0% (ohne Art. 6 Abs. 1)'), which caused multiple tax tags counted in the EC Sales report to be applied to the same line. This grouping behavior leads to double counting. ### Fix Repartition lines with the `tax_report_line_l10n_at_tva_line_4_8_tag` also contain the `tax_report_line_l10n_at_tva_line_3_zm_igl_tag`. To avoid double counting, the EC Sales Report now only checks for the latter tag. opw-4174429 Forward-Port-Of: odoo/enterprise#69941
This fix corrects how Mexican electronic invoices (CFDI) handle branch-specific information. Previously, invoices generated from a branch would incorrectly use the parent company's tax regime and company name. Now, invoices properly reflect the branch's tax regime while maintaining the root company name as required by Mexican tax authorities.
Original PR description
With an MX company setup Create a branch Change the fiscal regime of the branch to Arrendamiento (606). With the branch create an invoice and generate the CFDI Issues: - Regimen Fiscal in CFDI is set to the one of the parent company while it should be the one of the branch - When a PAC certificate is registered in the branch, company name in CFDI will be the branch name while it should always be the root company name opw-4097669