Monday, September 23, 2024
5 changes · 17.0
New functionality added to Odoo
This update adds a new Chrome extension for AEM with a built-in login form using default credentials. The extension includes the necessary configuration files, HTML interface, and placeholder icons to enable users to quickly access the system through their browser.
Original PR description
Sure! Here is a sample GitHub pull request description for the changes related to creating the Chrome extension with the default login functionality: --- ### Pull Request Title **Add Chrome Extension…
Sure! Here is a sample GitHub pull request description for the changes related to creating the Chrome extension with the default login functionality: --- ### Pull Request Title **Add Chrome Extension with Default Login Functionality** ### Description This pull request adds a basic Chrome extension for AEM, including a default login form with predefined credentials (username: `admin`, password: `admin`). The extension is structured with the necessary files and directories and includes placeholder icons. ### Changes Included 1. **Directory Structure:** - Created `aem-chrome-extension/` directory to hold extension files. - Created `aem-chrome-extension/images/` directory for icon files. 2. **Files Added:** - `index.html`: Contains the HTML structure for the login form. - `manifest.json`: Configures the Chrome extension settings. - Placeholder icon files (`icon16.png`, `icon48.png`, `icon128.png`). 3. **`index.html`:** - A simple login form with fields for username and password. - Inline CSS for basic styling. - JavaScript to handle login validation (checks for default credentials). 4. **`manifest.json`:** - Defined the extension name, version, description, and permissions. - Configured the extension's default popup to `index.html`. - Included paths to the placeholder icons. ### Testing 1. **Manual Testing Steps:** - Load the unpacked extension in Chrome (`chrome://extensions/` -> "Load unpacked"). - Verify that the login form appears when clicking the extension icon. - Test the login functionality with the default credentials (`admin`/`admin`). - Check that an alert is shown on successful or failed login attempts. ### Screenshots *If applicable, include screenshots here to show the extension UI and functionality.* ### Additional Notes - Placeholder icons are included and can be replaced with appropriate icons. - Future enhancements could include integrating with a backend for actual authentication, improving UI/UX, and adding more features. --- ### Checklist - [x] My code follows the style guidelines of this project. - [x] I have performed a self-review of my own code. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have made corresponding changes to the documentation. - [x] My changes generate no new warnings. - [x] I have added tests that prove my fix is effective or that my feature works. - [x] New and existing unit tests pass locally with my changes. --- ### References *Link any related issues, discussions, or other pull requests here.* --- Please review and provide feedback. Thank you! --- This template should help convey the purpose, changes, and testing process for your pull request clearly to the reviewers.
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