Friday, December 8, 2023
3 changes · master
Resolved issues and error corrections
Odoo now recognizes the port provided by a proxy server, so users accessing Odoo through a non-standard web port are no longer redirected to the wrong address. This improves reliability for companies hosting Odoo behind gateways such as Nginx.
Original PR description
Install nginx, setup it to listen on port 8080 instead of default 80
then setup a regular proxy_pass toward a local odoo listening on port
8069 with all the X-Forwarded- headers set:
listen 8080;
server_name mycompany.odoo.com;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Real-IP $remote_addr;
location / {
proxy_pass http://127.0.0.1:8069;
}
Inside your browser, access "http://mycompany.odoo.com:8080" you are
wrongly redirected to "http://mycompany.odoo.com:80".
The `X-Forwarded-Port` header wasn't taken into account by Odoo.
Closes: #64643Fixed an issue where employee avatar cards could fail to open when the Skills app was installed without Planning. Employee skills now display reliably because the shared tag display support is available from the core HR app.
Original PR description
Steps ===== - Install module hr_skills (but not planning) - Open the avatar card of an employee with skills linked to it Issue ===== A traceback appears indicating: "OwlError: Cannot find the definition of component "TagsList", missing static components key in parent". Cause ===== The AvatarCardResourcePopover component was patched in planning to add the component TagsList to it. This component was also used by the patch applied on AvatarCardResourcePopover in hr_skills. However, when hr_skills is installed but not planning, the component TagsList is used (to display the skills of the employee) but no append to the AvatarCardResourcePopover (or the AvatarCardEmployeePopover that inherits from it). Fix === The component TagsList is added in hr instead of planning as this module is required by both planning and hr_skills.
This fixes crashes when opening employee or resource avatar cards in cases where related modules or access rights differ. Users can now view relevant avatar details without unexpected errors, including planning users who do not have HR permissions.
Original PR description
[FIX] planning: add TagsList component to avatar card in hr instead of planning =============================================================================== Steps ----- - Install module hr_skills…
[FIX] planning: add TagsList component to avatar card in hr instead of planning =============================================================================== Steps ----- - Install module hr_skills (but not planning) - Open the avatar card of an employee with skills linked to it Issue ----- A traceback appears indicating: "OwlError: Cannot find the definition of component "TagsList", missing static components key in parent". Cause ----- The AvatarCardResourcePopover component was patched in planning to add the component TagsList to it. This component was also used by the patch applied on AvatarCardResourcePopover in hr_skills. However, when hr_skills is installed but not planning, the component TagsList is used (to display the skills of the employee) but no append to the AvatarCardResourcePopover (or the AvatarCardEmployeePopover that inherits from it). Fix --- The component TagsList is added in hr instead of planning as this module is required by both planning and hr_skills. [FIX] planning: avoid traceback for non hr-user when opening avatar card ======================================================================== Steps ----- - Install planning - Log in as a planning user with no hr access - Open the planning app - Click on the avatar of a resource with roles linked to it Issue ----- An access right error message appears indicating that the current user can't access the default_role_id field of the resource. Cause ----- This field of the resource.resource model is protected to user with hr access rights. In the avatar card component it was read, whatever the rights of the current user were. Fix --- A check on the access rights of the current user is added in the component to avoid to read that field if it is not allowed.