Tuesday, April 5, 2022
12 changes
Enhancements to existing features
Appointment managers can now access availability information directly from the kanban view even when an appointment type is not published. This makes it easier to review and manage appointment options before making them visible on the website.
Original PR description
When website is installed, provide quick access to appointment availabilities from kanban even for unpublished ones. Task-2816507
The mail app’s attachment preview tests were cleaned up by removing a simulated model that was no longer needed. This makes the test suite simpler and easier to maintain, helping reduce future maintenance risk without changing user-facing behavior.
Original PR description
task-2792108
This update adjusts the way test data is prepared for several communication-related apps, helping automated checks better reflect expected behavior. It supports more reliable validation for approvals, email collaboration, VoIP, and live chat helpdesk features without changing the user experience.
Original PR description
task-2792108
The update avoids saving default visitor session data when it is not needed, using direct location information instead. This helps reduce unnecessary stored data while keeping appointment and document signing flows working as expected.
Original PR description
See commit with same title in community. `request.session.geoip` -> `request.geoip` Companion of odoo/odoo#86015
Resolved issues and error corrections
This fixes payroll reporting behavior when dates are grouped and displayed using a user's regional settings. It helps prevent errors or incorrect date interpretation for users working in non-default locales.
Original PR description
When using read_group, dates are formatted using the user locale however when converting the date string to a real date, the user locale is not used.
Miscellaneous changes
General Ledger report (pdf or xlsx) contains wrong accounts when filtering on a partial account code Steps to reproduce: 1. Install and open Accounting 2. Go to Reporting > Audit Reports > General Ledger 3. In 'Search account' on the top right, filter on account 10 4. Print the pdf or the xlsx (there is an issue with printing in v13 at the moment so you might have to use the 'Save' button) 5. The report contains accounts that contain 10 inside their code but the accounts should only b
Original PR description
General Ledger report (pdf or xlsx) contains wrong accounts when filtering on a partial account code Steps to reproduce: 1. Install and open Accounting 2. Go to Reporting > Audit Reports > General Ledger 3. In 'Search account' on the top right, filter on account 10 4. Print the pdf or the xlsx (there is an issue with printing in v13 at the moment so you might have to use the 'Save' button) 5. The report contains accounts that contain 10 inside their code but the accounts should only be the ones that start with 10 Solution: Filter with `code%` instead of `%code%` so that only accounts that start with the code are provided opw-2799573 Forward-Port-Of: odoo/enterprise#25890 Forward-Port-Of: odoo/enterprise#25655
#### The issue At the moment, requesting the SAT status of a cancelled invoice returns ‘Not Found’. This is because the cancellation process deletes the cfdi attachment, on which several stored computed fields depend, notably the Fiscal Folio uuid. Without the uuid, we can't query the invoice’s status from the SAT. See this video by @vbe-odoo demonstrating the problem functionally: https://us02web.zoom.us/rec/play/7kRPfbcM1YixbiezgtHV0C9KAP6AwAmEzf05WtBJO2j3cLMpvSXznOad0qT2u0NoJsisH
Original PR description
#### The issue At the moment, requesting the SAT status of a cancelled invoice returns ‘Not Found’. This is because the cancellation process deletes the cfdi attachment, on which several stored…
#### The issue
At the moment, requesting the SAT status of a cancelled invoice
returns ‘Not Found’. This is because the cancellation process
deletes the cfdi attachment, on which several stored
computed fields depend, notably the Fiscal Folio uuid.
Without the uuid, we can't query the invoice’s status from the SAT.
See this video by @vbe-odoo demonstrating the problem functionally:
https://us02web.zoom.us/rec/play/7kRPfbcM1YixbiezgtHV0C9KAP6AwAmEzf05WtBJO2j3cLMpvSXznOad0qT2u0NoJsisH5ICFLfcxrNN.NjyNJHvBxfK2TNf3?continueMode=true&_x_zm_rtaid=xzBnPaTGTZiTv53zobKqqg.1646836564724.d211a63c07c388cdef9dfb832d780831&_x_zm_rhtaid=552
password: ?wgK1c$N
See this explanation of where the issue occurs in the source code:
https://drive.google.com/file/d/1z8GhsSk6nphmhB46C0wiDHMZjV7_QSZ8/view?usp=sharing
#### The solution
In stable: Retrieve the uuid from the attachment when querying the SAT
status. (this PR)
In master: Don’t delete the attachment when the invoice is
successfully canceled (https://github.com/odoo/odoo/pull/87142)
#### Does it work?
Yes. (See this video where I do the testing):
https://drive.google.com/file/d/1hac2dEwU6oFWDcLIC_CvxEIMObozQVY_/view?
Related support tickets
opw-2790491 opw-2716731
Forward-Port-Of: odoo/enterprise#25533Steps to reproduce the bug: - Install Helpdesk_stock - Remove Helpdesk access to Marc Demo - Connect as Marc - Go to any ‘Done’ transfer - Try to create a return Problem: An access error is triggered because we check if the picking is assigned to a helpdesk ticket, but the user does not have access rights. Solution: Use `sudo` to allow the user to check if the picking is linked to a helpdesk ticket in order to link the new return picking also even if he does not have helpdesk acces
Original PR description
Steps to reproduce the bug: - Install Helpdesk_stock - Remove Helpdesk access to Marc Demo - Connect as Marc - Go to any ‘Done’ transfer - Try to create a return Problem: An access error is triggered because we check if the picking is assigned to a helpdesk ticket, but the user does not have access rights. Solution: Use `sudo` to allow the user to check if the picking is linked to a helpdesk ticket in order to link the new return picking also even if he does not have helpdesk access opw-2795234 Forward-Port-Of: odoo/enterprise#25763
Purpose ======= Departure reasons could be used on business code (eg: payroll). Currently the mapping is made based on the xmlid, but it could happen for some customers to create several departure reasons of the same kind. (ex: "Resigned - Salary" or even "Resigned - Personal Reasons"). This commit uses the departure reason on _get_default_departure_reasons to allow considering them together. TaskID: 2811192 Forward-Port-Of: odoo/enterprise#25764
Original PR description
Purpose ======= Departure reasons could be used on business code (eg: payroll). Currently the mapping is made based on the xmlid, but it could happen for some customers to create several departure reasons of the same kind. (ex: "Resigned - Salary" or even "Resigned - Personal Reasons"). This commit uses the departure reason on _get_default_departure_reasons to allow considering them together. TaskID: 2811192 Forward-Port-Of: odoo/enterprise#25764
Fix a bug that caused traceback when editing a filter rangeType after changing its value. Fiexed it by removing values in filter_evaluation_plugin when the filter's rangeType change. Odoo task 2797617 Forward-Port-Of: odoo/enterprise#25678 Forward-Port-Of: odoo/enterprise#25497
Original PR description
Fix a bug that caused traceback when editing a filter rangeType after changing its value. Fiexed it by removing values in filter_evaluation_plugin when the filter's rangeType change. Odoo task 2797617 Forward-Port-Of: odoo/enterprise#25678 Forward-Port-Of: odoo/enterprise#25497
fix the bug by making /sign/update_user_signature 'public' before this commit: when a public user update the signature, there will be a popup for `session expired` Forward-Port-Of: odoo/enterprise#25866 Forward-Port-Of: odoo/enterprise#25803
Original PR description
fix the bug by making /sign/update_user_signature 'public' before this commit: when a public user update the signature, there will be a popup for `session expired` Forward-Port-Of: odoo/enterprise#25866 Forward-Port-Of: odoo/enterprise#25803
With 2 companies A and B: - insert a pivot in a spreadsheet with company A - switch to company B - go back to the spreadsheet => the data is loaded for company A instead of company B The full user context was mistakenly saved in the spreadsheet data (including `allowed_company_ids`, `lang`) and this context was used to fetch the pivot data. With this commit: - we no longer save user related context to pivot - we clean user related context before fetching. That's required for exi
Original PR description
With 2 companies A and B: - insert a pivot in a spreadsheet with company A - switch to company B - go back to the spreadsheet => the data is loaded for company A instead of company B The full user context was mistakenly saved in the spreadsheet data (including `allowed_company_ids`, `lang`) and this context was used to fetch the pivot data. With this commit: - we no longer save user related context to pivot - we clean user related context before fetching. That's required for existing spreadsheets. opw 2768620 task 2768169 Forward-Port-Of: odoo/enterprise#25859 Forward-Port-Of: odoo/enterprise#25612