Saturday, April 5, 2025
7 changes · saas-18.2
Miscellaneous changes
Reproduce: 1. Make a scored live session survey 2. Add a single choice question with a <0.5 point answer (or < 1 with speed reward) 3. Create a live session 4. Join with one participant 5. Play the survey, have the participant answer correctly (after half the time for speed reward if that case is tested) 6. Proceed to leaderboard and expect a crash. This happens because when `max_score` or `max_score_question` are <= 0.5, divisions by round(<=.5) are divisions by 0. Using 3 digits fo
Original PR description
Reproduce: 1. Make a scored live session survey 2. Add a single choice question with a <0.5 point answer (or < 1 with speed reward) 3. Create a live session 4. Join with one participant 5. Play the survey, have the participant answer correctly (after half the time for speed reward if that case is tested) 6. Proceed to leaderboard and expect a crash. This happens because when `max_score` or `max_score_question` are <= 0.5, divisions by round(<=.5) are divisions by 0. Using 3 digits for rounding has two advantages: * It is very unlikely that an answer will have a value below 0.0006 (not 0 - that case is supported- but rounds to 0). * It makes the template resilient to differences in precisions used for the various numbers (relevant in 17.4 where `answer_score` and `scoring_total` can be different by <0.01). Task-4655784 Forward-Port-Of: odoo/odoo#204907 Forward-Port-Of: odoo/odoo#203988
In the xml we sent, we have to specify the unit code, there is mapping for that on the documentation: https://developer.nilvera.com/en/code-lists#birim-kodlari This commit will extend what has been done in the base edi module with the UOM_TO_UNECE_CODE dictionary. We added some new unit of measure and each unit of measure will be linked to a code. The default value is C62. task-4457115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forw
Original PR description
In the xml we sent, we have to specify the unit code, there is mapping for that on the documentation: https://developer.nilvera.com/en/code-lists#birim-kodlari This commit will extend what has been done in the base edi module with the UOM_TO_UNECE_CODE dictionary. We added some new unit of measure and each unit of measure will be linked to a code. The default value is C62. task-4457115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204054 Forward-Port-Of: odoo/odoo#193030
… flexible This commit aims to resolve critical error in time off when the user is fully flexible. - get_allocation_data is updated to handle the case when the employee is fully flexible. - Set duration_hours and duration_days in the dummy attendance to handle flexible time off requests and to avoid unintended zero division error in _get_attendance_intervals_days_data. P.S: Currently Fully Flexible resources do not support fully time offs, so this allows a fallback that prevents
Original PR description
… flexible This commit aims to resolve critical error in time off when the user is fully flexible. - get_allocation_data is updated to handle the case when the employee is fully flexible. - Set…
… flexible This commit aims to resolve critical error in time off when the user is fully flexible. - get_allocation_data is updated to handle the case when the employee is fully flexible. - Set duration_hours and duration_days in the dummy attendance to handle flexible time off requests and to avoid unintended zero division error in _get_attendance_intervals_days_data. P.S: Currently Fully Flexible resources do not support fully time offs, so this allows a fallback that prevents error while still setting a valid duration of a time off request. Steps to reproduce: 1. Install hr_holidays 2. Go to Mitchel Admin's employee profile > work information 3. Delete the working calendar > so that the employee is fully flexible 4. Try to open time off module -> Prior to this commit, it would raise a zero division error ticket-id: 4677726 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204710 Forward-Port-Of: odoo/odoo#203737
Description of the issue/feature this PR addresses: This PR is to avoid making unnecessary format validations on manual documents, as well as to improve the error message shown when the validation is done and the user had entered an invalid document number. A use case for these changes is when the user wants to register an invoice from a foreign supplier that does not have the Uruguayan format, and at the moment of filling the “Document Number” field, an error message appears saying that it do
Original PR description
Description of the issue/feature this PR addresses: This PR is to avoid making unnecessary format validations on manual documents, as well as to improve the error message shown when the validation is…
Description of the issue/feature this PR addresses: This PR is to avoid making unnecessary format validations on manual documents, as well as to improve the error message shown when the validation is done and the user had entered an invalid document number. A use case for these changes is when the user wants to register an invoice from a foreign supplier that does not have the Uruguayan format, and at the moment of filling the “Document Number” field, an error message appears saying that it does not comply with the Uruguayan number validations. Current behavior before PR: Either electronic or manual document numbers format were validated against the electronic documents format. Desired behavior after PR is merged: Only electronic document numbers are validated to check if they have the proper format. Steps to reproduce the error: 1) Install l10n_uy 2) Create an invoice using a manual journal. 3) Set a random document number (for example '1234') 4) Check that a pop up is raised, saying that the format is invalid. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198216
**Problem**: Commit [f523cb8](https://github.com/odoo/odoo/commit/f523cb85174687856d2c93fbc3c2f52a307f6761) did not properly handle background images, leading to issues when retrieving the correct attachment source. **Solution**: Use `el.dataset.bgSrc` to get the correct attachment source for background images. **Steps to reproduce**: 1. Add a "Banner" block. 2. Update the image. 3. Save. - **Issue**: image lost. **opw-4686236** --- I confirm I have signed the CLA and read
Original PR description
**Problem**: Commit [f523cb8](https://github.com/odoo/odoo/commit/f523cb85174687856d2c93fbc3c2f52a307f6761) did not properly handle background images, leading to issues when retrieving the correct attachment source. **Solution**: Use `el.dataset.bgSrc` to get the correct attachment source for background images. **Steps to reproduce**: 1. Add a "Banner" block. 2. Update the image. 3. Save. - **Issue**: image lost. **opw-4686236** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204812 Forward-Port-Of: odoo/odoo#204662
**Steps to reproduce:** - Install Contacts, Accounting and l10n_be - Switch to a Belgian company (e.g. BE Company CoA) - In Accounting settings, activate "SEPA Direct Debit (SDD)" - Create a contact: * Country: Belgium * Bank Account: [a Belgian IBAN] - Go to "Accounting / Customers / Direct Debit Mandates" - Create a mandate for the created contact - Validate the mandate - Create an invoice for the created contact as customer - Confirm the invoice - Pay the invoice with "SEPA Di
Original PR description
**Steps to reproduce:** - Install Contacts, Accounting and l10n_be - Switch to a Belgian company (e.g. BE Company CoA) - In Accounting settings, activate "SEPA Direct Debit (SDD)" - Create a contact:…
**Steps to reproduce:** - Install Contacts, Accounting and l10n_be - Switch to a Belgian company (e.g. BE Company CoA) - In Accounting settings, activate "SEPA Direct Debit (SDD)" - Create a contact: * Country: Belgium * Bank Account: [a Belgian IBAN] - Go to "Accounting / Customers / Direct Debit Mandates" - Create a mandate for the created contact - Validate the mandate - Create an invoice for the created contact as customer - Confirm the invoice - Pay the invoice with "SEPA Direct Debit" - Print the invoice **Issue:** The information explaining that the invoice has been paid using direct debit and that the invoice should not be paid manually is not printed on the invoice. **Cause:** This information is printed if "sdd_mandate_id" field of the invoice is set. "sdd_mandate_id" is a related field to "origin_payment_id.sdd_mandate_id" field. However, since the refactoring on "account.payment", "origin_payment_id" is not set on an invoice anymore. It is just set on the journal entry linked to a payment. Therefore, we cannot rely on that field anymore to print the SDD mandate payment information. **Solution:** The "matched_payment_ids" field can be used instead. It's a Many2many field referring all payments linked to the invoice. If one of these payments has "sdd_mandate_id" set, the SDD mandate payment information is printed on the invoice. opw-4672191 Forward-Port-Of: odoo/enterprise#82823
This is more an UX problem rather than a bug. In the reconciliation tool, when you reconciled all the transactions of the current filter, rainbow mans appears. Then, all the background behind the rainbow overlay is disabled, you can no longer edit the filters in the search for instance, and the only buttons available become "All transactions" and "Back to dashboard". Both buttons will make you loose your search filters: - You loose the "Not Matched" filter which is set automatically when
Original PR description
This is more an UX problem rather than a bug. In the reconciliation tool, when you reconciled all the transactions of the current filter, rainbow mans appears. Then, all the background behind the…
This is more an UX problem rather than a bug. In the reconciliation tool, when you reconciled all the transactions of the current filter, rainbow mans appears. Then, all the background behind the rainbow overlay is disabled, you can no longer edit the filters in the search for instance, and the only buttons available become "All transactions" and "Back to dashboard". Both buttons will make you loose your search filters: - You loose the "Not Matched" filter which is set automatically when you hit the "x to reconcile" button in the accounting dashboard, and hence you see the already reconciled transactions, while you were actually interested only in the non-reconciled transactions - If you made a complicated filter, you loose them all and you are good to redo them all. This revision offers the possibility to have the background behind the rainbow overlay clickable, so you would be able to change the filters, for instance only the last filter, in order to continue your reconciliation where you were, instead of being completely reset. Before: https://github.com/user-attachments/assets/4ed7cf41-1fa0-4efe-92a0-171011b4713a After: https://github.com/user-attachments/assets/e4f2d580-9dca-4331-9e66-89efeb00edef Forward-Port-Of: odoo/enterprise#82562