Thursday, August 29, 2024
7 changes · 17.0
Enhancements to existing features
This update improves the performance of the messaging system by preventing duplicate notification broadcasts across multiple modules. The change ensures that after system resets, notification tracking starts fresh, reducing unnecessary processing and improving overall system responsiveness for users relying on real-time messaging features like chat and helpdesk support.
Original PR description
* = documents_spreadsheet, website_helpdesk_livechat, whatsapp Enterprise counter-part. After a reset, the last id is always 0. backport of https://github.com/odoo/enterprise/pull/68302 community: https://github.com/odoo/odoo/pull/177705
Resolved issues and error corrections
This fix prevents users from submitting documents without actually signing them. Previously, users could submit a document in Draw mode without drawing a signature, resulting in unsigned documents being sent. The fix now properly disables the submit button when no signature has been created, ensuring documents can only be submitted after a valid signature is provided.
Original PR description
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we…
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we are able to submit the sign even before drawing anything, which will allow us to send the document "unsigned", since there will not be any sign. ## Steps to reproduce: 1. Get Sign module. 2. Upload any document to sign. 3. Add sign box and go to sign the document. 4. Now change from Auto to Draw. ## Solution: We should take into account that it makes sense that everytime we update if our signature is empty, we update the state of the buttons accordingly avoiding this way to be able to sign without an actual sing. The solution address a similar approach at what was already being done with the onChangeName, we move this logic to be handled by a specific function for this buttons 'handleButtonStateChange'. The fix is part of > [#164410](https://github.com/odoo/odoo/pull/164410) opw-3874034
Fixed an issue where field service technicians assigned to tasks couldn't see those tasks in their Field Service view, even though they were task followers. The fix ensures that users with limited project access can still view and work on tasks they're assigned to, improving workflow visibility for team members with restricted permissions.
Original PR description
Steps to reproduce: - Log in as admin - Project > Configuration > Projects > Field service - In the Settings tab set Visibility to 'Invited Internal Users' - Create a task with Marc Demo as assignee…
Steps to reproduce:
- Log in as admin
- Project > Configuration > Projects > Field service
- In the Settings tab set Visibility to 'Invited Internal Users'
- Create a task with Marc Demo as assignee
- Check that Marc Demo is a follower of the task and not of the project
- Settings > Users & Companies > Users > Marc Demo
- Set Marc Demo's access rights for Project and Field Service to 'User'
- Log in as Marc Demo > Field Service
- No tasks are displayed
As per the specifications of the 'Invited Internal Users' mode of project privacy, a user should be able to see tasks they are a follower of even if they do not have access to the project they are from. This is correctly reflected in Projects > Tasks > My Tasks where the followed task is visible.
This does not happen because of a lack of access rights on the task as we can copy the url of the task in Field Service as admin and access the page when pasting it as demo.
The issue here is threefold:
- The domain we use filters tasks by (project_id != False), but the project is not acessible to us so we cannot read that field. This is however redundant since the domain also contains a check on is_fsm which is read on the project, ensuring it exists.
- is_fsm is currently a field defined with both 'related' and 'search' arguments. Prior to 17.2, search is ignored in favor of search_related so the domain once again tries and fails to access the information on the related project. The search function defined here (which was previously unused) bypasses the issue by getting is_fsm through an SQL query.
- Since is_fsm is not storable on task, the search function is used to translate domains of type ('is_fsm', '=', ...). However the _search_is_fsm function did not take into account the value passed as argument (only the operator), resulting in domains like ('is_fsm', '=', 'False') not being inverted as they should.
opw-4003133This update corrects the payroll category structure for Slovak HR payroll, ensuring that deduction and allowance categories are properly assigned to employee rules only. Additionally, a data file was renamed to maintain consistency with other payroll modules in the system.
Original PR description
With this commit, some rules category are fixed : deduction, allowance are set only on employee rule. One file's name changed to be coherent with others payrolls. task-4069829
This fix resolves an issue where the rental period field was hidden when users created new rental orders through the Schedule feature in the rental module. The rental period is now properly displayed instead of being replaced by the payment period, allowing users to correctly set rental dates when creating orders.
Original PR description
…ew ro Version: 17.0 Steps: Click on the schedule feature in the rental module. Click on the 'New' to create the rental order. Issue : When a user clicks on the "Schedule" feature in the rental module and then clicks on "New" to create a rental order, the rental period feature is disabled, and the payment period appears instead. Cause : The issue is caused by the condition invisible="not is_rental_order" on the rental_start_date field. fix: To fix this issue, we remove the invisible="not is_rental_order" condition from the rental_start_date field definition. This ensures that the rental period feature is always visible when creating a new rental order. opw-4016866
This fix resolves an issue where helpdesk teams in multi-company environments were incorrectly assigned field service projects from the wrong company, causing access errors. The system now properly assigns the correct field service project based on each team's assigned company, ensuring users can access their helpdesk team settings without errors.
Original PR description
Problem: Upon installing helpdesk_fsm in a multi-company setup, the default fsm project when enabling "use_fsm" on helpdesk teams is incorrectly retrieving the fsm project from the wrong company. This leads to a multi-company access error when trying to navigate to the fsm project linked to the helpdesk teams. Purpose: Instead of incorrectly defaulting the fsm project from the wrong company upon installation using a default method, compute the default of fsm project based on the team's company. Steps to Reproduce on Runbot: 1. Install Project, Field Service, and any l10n module 2. Switch to the localized company 3. Create a helpdesk team 4. Install the helpdesk_fsm module 5. Navigate to the helpdesk team settings 6. Enable "use_fsm" on the team 7. Try to access the default fsm project 8. multi-company AccessError is thrown opw-3989799 Forward-Port-Of: odoo/enterprise#68831 Forward-Port-Of: odoo/enterprise#65701
This update fixes a bug where clicking the partner ledger button from a customer or vendor record was incorrectly opening a detailed transaction list instead of the Partner Ledger report. Now users will see the correct Partner Ledger report view when accessing it directly from a partner record, providing a better experience when reviewing partner financial information.
Original PR description
[FIX] account_reports: fix opening of partner ledger from partner Fix when opening the partner ledger directly from res.partner button it goes to account.move.line insted of Partner Ledger report Signed-off-by: David Goldfeder <dgw@appti.mx> 17.0 Mexico, 2024-05-05 Appti agrees to the terms of the Odoo Corporate Contributor License Agreement v1.0. I declare that I am authorized and able to make this agreement and sign this declaration. Signed, David Goldfeder <dgw@appti.mx> https://github.com/appti-mx List of contributors: David Goldfeder <dgw@appti.mx> https://github.com/appti-mx