Monday, June 24, 2024
19 changes · 17.0
Resolved issues and error corrections
Fixed a bug where creating a 15-minute appointment slot in the calendar would incorrectly create two slots instead of one. The issue was caused by the calendar library detecting both a date selection and a click event. The fix prevents the duplicate slot creation by ignoring the second event, ensuring users get exactly one slot when they intend to create one.
Original PR description
When trying to create a custom slot of 15min in the calendar, two slots were created. This was because the fullcalendar library was detecting two events: a date selection and a date click. The date selection is correct but the size of the event (15 min) is the minimal size which execute a click using the default time. To prevent this behaviour, we use preventDefault to ignore the second event and so the creation of the second slot. task-3976122 Forward-Port-Of: odoo/enterprise#64000
The accounting dashboard now correctly filters out draft and cancelled payments in the Bank > Payments view by default. This ensures the total amount shown on the dashboard card matches the actual sum of displayed payments, eliminating confusion from inconsistent data.
Original PR description
Problem --- In the accounting dashboard, when going to Bank > Payments draft and cancelled payments are not filtered out by default. This makes the amount displayed on the kanban card inconsistent with the sum of the payments that are shown by default. opw-3978180
This fix resolves an access error that prevented accountants from rematching GSTR-2b tax reports in India. Users with Accountant access rights can now successfully rematch GSTR-2b summaries without encountering permission errors, improving the tax reporting workflow for Indian companies.
Original PR description
This commit fixes the access error that occured while trying to rematch gstr-2b report Behaviour before this commit: When user tries to rematch the GSTR-2b Summary, an access error will be thrown that says user has no read access to the Attachments. Steps to reproduce: - Login with a user having `Accountant` group set in access rights for Account. - Install l10n_in_reports_gstr module & Switch to IN Company - Go to Accounting / Reports / GSTR Return Periods - Create new return period. - Fetch GSTR-2b Summary and try to re-match. (An access error will popup)  Behaviour after this commit: The access error is no longer visible. Re-match can be done successfully.
This update fixes a test in the Luxembourg tax reporting module that was not properly respecting tax lock date restrictions. The fix ensures the test will continue to work correctly after an upstream improvement to tax lock date validation. This is a maintenance update that prevents test failures and ensures the tax reporting system functions as intended.
Original PR description
Currently the tax lock date is not checked correctly in a test when posting a move. This problem is solved in the related community PR. This commit ensures the test does not fail after the community fix. To do this we just remove and re-introduce the tax lock date. community PR: https://github.com/odoo/odoo/pull/170475
This update fixes a button contrast issue in the Sign module that was making text difficult to read. By removing an unnecessary styling class, the button now displays with proper contrast in both light and dark modes, improving the user experience without requiring any action from users.
Original PR description
This PR fixes a contrast issue on a primary button within the sign module due to a `text-white` class applied. The default button utility classes already provide a good contrast, meaning that adding extra class is not useful. To fix the issue, we simply remove the class from the button. task-3692048 | Light mode (`:focus` state) | Dark mode | |--------|--------| | <img alt="image" src="https://github.com/odoo/enterprise/assets/128030743/b73a2fe7-f802-4461-9015-16a2f4b46d92"> | <img alt="image" src="https://github.com/odoo/enterprise/assets/128030743/8354c78f-6525-4aef-9057-fdb706b3cd0d"> |
A recent change prevented users from reconciling bank journal entries with credit card accounts. This fix restores that capability by allowing reconciliation with credit card and other liquidity accounts, while still preventing reconciliation with the same account set on the journal itself. This ensures users can properly match transactions across different account types.
Original PR description
After [this commit], when we allowed credit card accounts on bank journals, we changed the domain of the manual bank reconciliation widget to also make credit card accounts not selectable anymore. However, people are currently reconciling their bank journal entries with a credit card account, which is not possible anymore after this change. This commit fixes that by only preventing to reconcile with the same account as the one set on the journal. [this commit]: https://github.com/odoo/enterprise/commit/4f84a260e515cc5d52d7aa2d9ba0dca7d77a101c Forward-Port-Of: odoo/enterprise#65082 Forward-Port-Of: odoo/enterprise#64877
This update fixes a restriction that was preventing users from deleting electronic documents (EDI) associated with vendor bills and vendor bill refunds in Mexico. Previously, a blanket restriction was applied to all EDI documents to protect those sent to the government, but vendor bills don't require this protection. Users can now delete these documents as needed.
Original PR description
In fc84a6e a fix was added to prevent deleting EDI documents as they're sent to the government. This is not the case for vendor bills and vendor bill refunds. This commit allows the deletion of the documents for those move types. task-3999152 Forward-Port-Of: odoo/enterprise#64974
This update removes duplicate code from the Chilean EDI module that has been consolidated into the core Chilean localization module. By eliminating redundant methods for amount calculations and VAT formatting, invoices generated in currencies other than the default will now display correctly in PDF format. This cleanup improves system efficiency and ensures consistent invoice presentation across different currencies.
Original PR description
Methods from l10n_cl_edi are being moved to l10n_cl as part of https://github.com/odoo/odoo/pull/133695. This includes _l10n_cl_get_amounts and _float_repr_float_round on the account move model, as well as the method _l10n_cl_get_line_amounts on the account move line model. They can therefore be removed in this commit. The VAT section for the electronic ticket document is also being transferred in the same manner, and can thus be removed in the template here. This will allow to show the PDFs of invoices generated in other currency in a correct way. X-original-commit: 135a9bee298fe77217548d2fe86ae2558878e5b7 (cherry picked from commit 6ac7ebd00f0e63d4927e05f85ee45b96c7def4e3) Forward-Port-Of: odoo/enterprise#60890
A recent system update automatically assigns a country to companies based on their chart template. This caused Peru sales tests to fail because document validation rules were unexpectedly triggered. This fix updates the tests to properly handle the new document requirement validation.
Original PR description
With this commit: https://github.com/odoo/odoo/pull/166896/commits/90088bd97ec096fa8c360868e3a1addef91bd4ce We automatically add the country of the chart template to the company if the company does not have one by default. This change had a side effect that in the context of the test "TestPeSales," the boolean field l10n_latam_use_documents on the journal was now set to True. The consequence of that was that the constraint _check_l10n_latam_documents was breaking since this constraint checks that for the posted moves that use documents, the move must have a document type and a document number. task: 3945833
Corrected an issue where payment amounts were incorrectly displayed in EUR currency regardless of the actual transaction currency. The fix ensures that EUR currency is only shown when using the SEPA Direct Debit payment provider, preventing confusion when customers pay in other currencies like USD.
Original PR description
To reproduce the issue: 1. Go to the wire transfer provider and enable it 2. Make sure there is a “Pending Message", if not click “Reload Pending Message” 3. Create a quotation in USD 4. Send by Email 5. Preview 6. Accept & Sign 7. Pay Now 8. Select Wire Transfer and Pay The amount will show under communication with as EUR. To fix it, only show this when the SEPA provider is used. opw-4006206 PS: I targeted 17 because it's the closest stable release to odoo.com (where we experience the issue). Seemingly no one else has run into this over the years so I didn't want to change previous versions needlessly.
This update corrects how the end date is calculated for salary attachments. Previously, the system incorrectly used today's date as the starting point for this calculation. Now it properly uses the salary attachment's actual start date. The change also adds a new field to display the duration of each attachment, making it easier to track how long attachments are in effect.
Original PR description
Before, the end date of salary attachment was computed using today's date as a starting point. It really should be the salary attachment's starting date. Also, this will add a computed field to see the duration of the attachment. Task: 3947494 Forward-Port-Of: odoo/enterprise#63361
This fix resolves an access permission error that occurred when creating helpdesk tickets for internal users with empty phone numbers. The system now properly handles phone number updates for internal users without triggering access restrictions, ensuring helpdesk staff can create and manage tickets smoothly.
Original PR description
Steps to reproduce: - Install Helpdesk - Create two internal user with admin access to Helpdesk - Log as the first user and create a ticket for the second user with empty phone Issues: An access error is shown as we do not have the rights to write on the partner phone. To fix this issue a sudo was added as well as a filter in the inverse to make sure we skip ticket without a partner phone in the inverse. opw-3989614
This fix prevents article templates from appearing in helpdesk customer portal search results. Previously, when the Knowledge module was updated to use templates, the helpdesk integration was not updated to filter them out, causing templates to be visible to customers alongside regular articles. This fix ensures only actual articles are shown to users.
Original PR description
When we introduced dynamic templates in Knowledge, we merged the models `knowledge.article` and `knowledge.article.template` and introduced a new field `is_template` in the `knowledge.article` model…
When we introduced dynamic templates in Knowledge, we merged the models `knowledge.article` and `knowledge.article.template` and introduced a new field `is_template` in the `knowledge.article` model to distinguish the templates from the regular articles. In the `website_helpdesk_knowledge` module, we forgot to exclude the templates from the search domains. As a result, the helpdesk frontend view can list and search within templates. Steps to reproduce the issue: 1. Log in as "Admin". 2. Install `website_helpdesk_knowledge` module. 3. Go on the Helpdesk module. 4. On the helpdesk overview, click on the vertical dots of the "Customer Care" team card. 5. On the dropdown menu, click on the "Settings" option. 6. On the "Help Center" section, click on the "Knowledge" option. 7. On the "Visibility & Assignment" section, click on "Invited portal users and all internal users" option. 8. Save the changes. 9. Go on the Website module. 10. On the website navbar, click on "Customer Care" nav bar. 11. The interface should list article templates. => TO BE: The system should not list any templates. To fix that issue, we will simplify the search domains and exclude the templates from the search results using the `is_template` field. Reference: https://github.com/odoo/enterprise/pull/48691 task-3987469
Fixed a crash that occurred when using keyboard navigation in the document split tool after pages were removed. Users can now navigate through documents without encountering errors, and the system will automatically focus on the first page if the target page is no longer available.
Original PR description
Steps to reproduce: 1. Open the split tool, select a few pages, and create an expense for instance 2. Once the pages are gone, navigate with the keyboard 3: Traceback occurred Technical reason: When we navigated using the left arrow, it couldn't find the documents we were targeting. In the '_focusNextPage' function, inside 'PdfManager' it was attempting to access elements like 'arr[-2]', which resulted in an 'undefined' value. After this commit: No traceback will occur and if it can't find the previous or next selected page, it focuses on the first page by default. Task-3874151
This fix corrects how excess items scanned during barcode picking operations are visually marked. When warehouse staff scan more items than originally planned, these excess lines now properly display with a distinct visual indicator (faulty class) to clearly show they were not part of the original picking plan. This improves inventory accuracy and reduces confusion during the picking process.
Original PR description
**Current behavior:** Excess lines which are created during a barcode picking flow do not get the o_faulty class which distinguishes them as not being planned during the picking's creation. **Expected behavior:** These extra lines will get the o_faulty class. **Steps to reproduce:** 1. Create a picking in the Inventory app, mark it as to-do 2. In the Barcode app, go to the picking and scan the product 3. After scanning the original demand quantity, scan it again 4. See that it doesn't get the o_faulty class **Cause of the issue:** The lineIsFaulty() method is checking defunct properties to determine whether they should get this css class. **Fix:** Update the check so it uses an existing property. opw-3904661 Forward-Port-Of: odoo/enterprise#63285
This fix removes an unnecessary requirement for organization ID information when generating SEPA Credit Transfer (SCT) payment files. Previously, the system would block file generation if this field was empty, but according to the latest European Payments Council standards, this field is optional. Now users can generate SCT files without this information, making the payment process more flexible.
Original PR description
Following the doc https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2023-11/EPC132-08%20SCT%20C2PSP%20IG%202023%20V1.1.pdf , InitgPty/Id is not required in the XML file. We used to block the generation if we had no value to put in it; not anymore. opw-3985622 Forward-Port-Of: odoo/enterprise#65214
The Planning app has been updated to display only shifts that match an employee's assigned roles, rather than showing all available shifts. This ensures employees see a more relevant and personalized list of open shifts when they access the planning application, making it easier to find opportunities that match their qualifications.
Original PR description
Issue Currently, internals users are shown all the open shifts when they arrive on the planning app, even if the shift's role is not one of the user's role. Fix - If the employee doesn't have any roles, show all open shifts. - If the employee has role(s), show the open shifts with that role or no role. To do this, we modify the open shifts filter (which is set by default for internal users) to only show open shifts matching the user's role in the default Gantt view. opw-3888507
This update ensures that approval rules configured in Studio are now included when exporting Studio customizations. Previously, approval rules were not being exported, which could result in incomplete customization transfers between environments. This fix ensures all Studio configurations are properly preserved during export operations.
Original PR description
Add the studio.approval.rule models in the default models to studio export. Task-3748219 Forward-Port-Of: odoo/enterprise#57038
This update configures the translation system to properly export Swiss payroll-related text for translation into other languages. By adding these terms to the translation configuration, the Swiss payroll module can now be fully localized, ensuring that payroll documents and communications are available in multiple languages for international teams.