Thursday, October 21, 2021
31 changes · master
Enhancements to existing features
HR menu labels were updated to consistently use “plan” instead of mixing “plan” and “planning.” This makes the employee plan options easier to understand and better aligned with related action titles.
Original PR description
To avoid mixing both plan and planning in hr plan options it was decided to reword menus to plan instead of planning. TaskId-2664863
Department forms now include an Employee button, making it easier for users to see related employees directly from the department record. This improves navigation for HR teams and reduces the need to search separately for staff by department.
Original PR description
Show an "Employee" stat button on the department form view. TaskID: 2672986 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now uses the website domain saved in the database directly, because domain cleanup already happens before saving. This removes older internal cleanup logic and keeps website, forum, and profile links simpler without changing expected user behavior.
Original PR description
Before Odoo saas-14.4, one should call `_get_http_domain()` on website to get its domain. Indeed, that method was in charge of cleaning that domain, as it was done with commit [1]. Since Odoo saas-14.4, that cleaning is automatically performed on domain before saving it into database, thanks to commit [2]. Thus, we can now remove the `_get_http_domain()` and use directly the domain as it is considered clean. Note that migrated databases coming from version older than Odoo saas-14.4 could still have an incorrect domain (trailing slash, no scheme..). This will be handled during migration with [3]. [1]: https://github.com/odoo/odoo/commit/3ad775aab717b395a5d11527aeb3596af66afa99 [2]: https://github.com/odoo/odoo/commit/042c95b0219bb0aa13e73385e092fa76ff1a1b0a [3]: https://github.com/odoo/upgrade/pull/2951 task-2674684
Websites with a configured domain will now discourage search engines from indexing the same site when it is accessed through another domain, such as an Odoo-hosted address. This helps avoid duplicate search results and keeps traffic focused on the intended public domain.
Original PR description
**Description of the issue/feature this PR addresses:** Currently, search engines index a SAAS-hosted website twice (once for the actual domain, and once for the .odoo.com domain) which is something that should be preventable. **Desired behavior after PR is merged:** If a domain name is configured, and the website is accessed through a different domain than the configured one, the noindex tag appears and robots.txt forbids crawlers, preventing them from indexing it. This change should work retroactively, meaning that if adopted, domains which are not the main configured one will be unindexed from search engines as soon as they're crawled. task-2418904
Belgian payroll users can now generate a PDF summary of the DmfA declaration information that needs to be entered. This helps companies handle declarations manually when batch submission is too complex or requires technical expertise.
Resolved issues and error corrections
Fixed an issue where employee shifts could default to a full day when the scheduler and employee were in different time zones. Default shift hours are now based on the employee's work schedule, helping avoid incorrect overnight or overly long shifts.
Original PR description
Description of the issue/feature this PR addresses: The search range for the closest work time is not assigned any value if the start date is different than the end date. The dates can be different…
Miscellaneous changes
This PR fixes multiple issues in project profitability report. Steps to reproduce opw-2596224: - Go to sale - Make a RFQ for a service product with service_policy set at delivered_timesheet (Timesheets on tasks), set quantity as 10 - Confirm order and create two invoices for 15%, confirm the two invoices - Create a credit note for one of the invoice and confirm it - Go back to the Sale Order and click on Project Overview => Inconsistencies (Downpayment reported twice) - Add an expens
Original PR description
This PR fixes multiple issues in project profitability report. Steps to reproduce opw-2596224: - Go to sale - Make a RFQ for a service product with service_policy set at delivered_timesheet…
This PR fixes multiple issues in project profitability report. Steps to reproduce opw-2596224: - Go to sale - Make a RFQ for a service product with service_policy set at delivered_timesheet (Timesheets on tasks), set quantity as 10 - Confirm order and create two invoices for 15%, confirm the two invoices - Create a credit note for one of the invoice and confirm it - Go back to the Sale Order and click on Project Overview => Inconsistencies (Downpayment reported twice) - Add an expense => Inconsistencies in expense amount untaxed invoiced - Add timesheets - Create an invoice from the SOL => Inconsistencies in Other costs, counting the downpayment. This issue is fixed by : - Excluding downpayments which are linked to a reversed invoice line - Use expense amount to invoice and expense amount invoiced separetely in the project overview. - Do not report not invoiced SOLs in the expense amount invoiced. - Exclude negative amounts in analytic account which are linked to credit notes. opw-2596224 opw-2631163 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78523 Forward-Port-Of: odoo/odoo#78230
Description of the issue/feature this PR addresses: The search range for the closest work time is not assigned any value if the start date is different than the end date. The dates can be different if the employee is in another timezone. Current behavior before PR: If the browser time is UTC+2 and a shift of an employee in UTC+6 is scheduled, the start time in UTC time will be 01/01/2000 22:00 and the end time will be 02/01/2000 21:59:59. Converted to the resource.tz timezone, the start date will become 02/01/2000 and the end date will be 03/01/2000. Due to the date difference, the search range is not assigned a value, the start of the shift will be at the employee start time on 02/01/2000 and the end of the shift will be around lunch break one day later. Desired behavior after PR is merged: The shift of the employee for a certain day doesn't span over two days or exceeds the hours per day for the employee Related to https://github.com/odoo/enterprise/pull/20428 Task-2628876 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents employee shifts from accidentally stretching across two days when browser and employee time zones differ. It helps ensure planned work hours match the employee's daily schedule and avoids incorrect shift lengths around time zone conversions.
Original PR description
Description of the issue/feature this PR addresses: The search range for the closest work time is not assigned any value if the start date is different than the end date. The dates can be different…
Description of the issue/feature this PR addresses: The search range for the closest work time is not assigned any value if the start date is different than the end date. The dates can be different if the employee is in another timezone. Current behavior before PR: If the browser time is UTC+2 and a shift of an employee in UTC+6 is scheduled, the start time in UTC time will be 01/01/2000 22:00 and the end time will be 02/01/2000 21:59:59. Converted to the resource.tz timezone, the start date will become 02/01/2000 and the end date will be 03/01/2000. Due to the date difference, the search range is not assigned a value, the start of the shift will be at the employee start time on 02/01/2000 and the end of the shift will be around lunch break one day later. Desired behavior after PR is merged: The shift of the employee for a certain day doesn't span over two days or exceeds the hours per day for the employee Related to odoo/enterprise#20428 Task-2628876 ref #75527 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Indian Payroll app now only shows the Payment Advices menu to users who can access an Indian company. This reduces confusion for users working with payroll in other countries by hiding functionality that does not apply to them.
Original PR description
Purpose - When you install Indian Payroll, you get a new functionality: Payment Advices, which is irrelevant for the other localizations. If the user does not have access to any of the Indian companies, hide the menuitem 'Payment Advices'. task - 2533672
This fixes shift planning so default start and end times come from the employee's working schedule, even when they are on leave or in a different timezone. It prevents shifts from incorrectly defaulting to all-day hours, making schedules more accurate for planners and employees.
Original PR description
Description of the issue/feature this PR addresses: In planning, version 14.0: - Create a shift for the employees that are on time off and on the day they are on leave - Create a shift for the employees on a different timezone from the working hours The default hours are 00:00 - 23:59, the default hours should be based on the employee's resource calendar Current behavior before PR: If the user is in a different timezone of if the employee is on leave on the day of the shift, the work interval is not found and defaulted to 00:00 - 23:59 Desired behavior after PR is merged: The default hours for the shift should be based on the employee's resource calendar task-2632775 ref https://github.com/odoo/enterprise/pull/20428
Planning shifts for employees without linked user accounts now default to the employee's own work schedule instead of filling the entire day. This prevents incorrect 00:00-23:59 shifts when users and employees are in different time zones, improving planning accuracy.
Original PR description
Steps to reproduce: https://drive.google.com/file/d/1MngJC_OF-6hsygRKJrbmRohyDXaLd6oD/view create a shift for an employee that isn't linked to a user Observed behavior: the default hours are 00:00 -…
Steps to reproduce: https://drive.google.com/file/d/1MngJC_OF-6hsygRKJrbmRohyDXaLd6oD/view create a shift for an employee that isn't linked to a user Observed behavior: the default hours are 00:00 - 23:59 Expected behavior: the default hours should be based on the employee's resource calendar The issue appeared when the timezone of the user was changed. There was a condition in planning/models/planning.py that was checking the employee's schedule only when the user's timezone was equal to the the employee timezone. This condition has been removed. The default hours of employees are now computed based on the employee's schedule. The existing test in planning/tests/test_form.py has been rewritten: - The slot is created by a user in the Europe/Brussels timezone for an employee in India/Calcutta having a 38 hours per week schedule - The slot is planned for one day between 00:00 and 23:59 - Once the slot is created, the start and end hours of the slot are checked against the employees' schedule on the specific day of the week Task-2628876
Sets the `inventory_quantity_set` as an editable field (not readonly) and creates its own compute to avoid to override it each time the `inventory_quantity` is modify and we set the `inventory_quantity_set` aside (before this commit, this field new value was always overrided by the `inventory_diff_quantity` compute). This is useful when we want to write on the quants from the Barcode App as we can write on `inventory_quantity` and `inventory_quantity_set` at the same time. task-2632818 Forw
Original PR description
Sets the `inventory_quantity_set` as an editable field (not readonly) and creates its own compute to avoid to override it each time the `inventory_quantity` is modify and we set the `inventory_quantity_set` aside (before this commit, this field new value was always overrided by the `inventory_diff_quantity` compute). This is useful when we want to write on the quants from the Barcode App as we can write on `inventory_quantity` and `inventory_quantity_set` at the same time. task-2632818 Forward-Port-Of: odoo/odoo#76756
Forward-Port-Of: odoo/odoo#78686
Original PR description
Forward-Port-Of: odoo/odoo#78686
When visiting a page with enable_editor set to true, the web editor will be automatically started. However, while the editor is loading, the end user can still click other buttons in the navbar. For example, some changes in the web editor require a save and reload of the current page being edited. After saving, the same page will be reloaded with enable_editor. This PR blocks any clicks while the editor is being loaded. task-2607755 Forward-Port-Of: odoo/odoo#77428
Original PR description
When visiting a page with enable_editor set to true, the web editor will be automatically started. However, while the editor is loading, the end user can still click other buttons in the navbar. For example, some changes in the web editor require a save and reload of the current page being edited. After saving, the same page will be reloaded with enable_editor. This PR blocks any clicks while the editor is being loaded. task-2607755 Forward-Port-Of: odoo/odoo#77428
Ensure that all models have their own explicit definition of identifying fields. Prior to this commit, if a model did not have identifying fields, the ones in mail.model were used implicitly because of the inheritance. Forward-Port-Of: odoo/odoo#78692
Original PR description
Ensure that all models have their own explicit definition of identifying fields. Prior to this commit, if a model did not have identifying fields, the ones in mail.model were used implicitly because of the inheritance. Forward-Port-Of: odoo/odoo#78692
In task-2355704 changes were made to the pdf layout designer to allow more flexibility when setting company data. However, for the default values of both company_details and report_footer, the data wasn't being escaped, which could corrupt the HTML code, even if it is sanitized. Also, they didn't take into account the address_format when computing the default value. This PR implements Markup usage in the html fields and fixes _default_company_details to use the set address_format. Bug report
Original PR description
In task-2355704 changes were made to the pdf layout designer to allow more flexibility when setting company data. However, for the default values of both company_details and report_footer, the data wasn't being escaped, which could corrupt the HTML code, even if it is sanitized. Also, they didn't take into account the address_format when computing the default value. This PR implements Markup usage in the html fields and fixes _default_company_details to use the set address_format. Bug report courtesy of Abdelkader Mouaz Forward-Port-Of: odoo/odoo#78652
The purpose of this commit is to display the project name and task to the right of the div in the activity view. before this commit, the project name and task displays next to the many2many_tags div in the activity view. TaskID-2646204 Forward-Port-Of: odoo/odoo#76681
Original PR description
The purpose of this commit is to display the project name and task to the right of the div in the activity view. before this commit, the project name and task displays next to the many2many_tags div in the activity view. TaskID-2646204 Forward-Port-Of: odoo/odoo#76681
…ueries The active field of stock.valuation.layer is related to product_id.active. Since product_id is a Many2one stored field without auto_join, when performing `self.env['stock.valuation.layer'].search(domain)` without `active_test=False`, the domain expression will be extended with `[('product_id.active', '=', 1)]`. Evaluating this expression in `expression.parse(self) L.912` will inject all the active product_ids found in the database. This makes it quite slow for psql to parse the
Original PR description
…ueries The active field of stock.valuation.layer is related to product_id.active. Since product_id is a Many2one stored field without auto_join, when performing…
…ueries
The active field of stock.valuation.layer is related to product_id.active.
Since product_id is a Many2one stored field without auto_join, when performing
`self.env['stock.valuation.layer'].search(domain)` without `active_test=False`, the domain
expression will be extended with `[('product_id.active', '=', 1)]`. Evaluating this expression
in `expression.parse(self) L.912` will inject all the active product_ids found in the database.
This makes it quite slow for psql to parse the select queries when the number of active
products in a database is big, as the where condition is a series of AND.
To avoid that, add `auto_join=True` for the `product_id` Many2one.
#### Speedup
Reported speedup of `web_read_group` of `Inventory > Reporting > Inventory Report` for the same company_id
| Number of active products | current timing | timing with auto_join |
| :--------------------------: | :--------------: | :--------------------: |
| 1.000 | 8s | 1.2s
| 20.000 | 15s | 1.2s |
| 100.000 | 40s | 1.2s |
| 500.000 | 2min30s | 1.3s |
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#68905Currently, projects that are 'on hold' stage are represented in grey in the kanban progress bar while the colored dot on their card is in blue. In this commit, we change the color of the 'on hold' stage into 'info' instead of 'muted'. After this projects that are 'on hold' are display blue in the kanban progress bar as well. Task-Id:2633273 PR: #76355 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:
Original PR description
Currently, projects that are 'on hold' stage are represented in grey in the kanban progress bar while the colored dot on their card is in blue. In this commit, we change the color of the 'on hold' stage into 'info' instead of 'muted'. After this projects that are 'on hold' are display blue in the kanban progress bar as well. Task-Id:2633273 PR: #76355 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#76355
This commit ensure the pricelists are properly configured before launching a pos session. Steps to reproduce: - Have a V13 with point_of_sale - Have minimum 2 companies A & B - Select both companies in the company selector - Go to Settings / General Settings - Point of Sale - Check Pricelists - Go to Point of Sale - Open a pos.config PC - Set a Pricelist PL as Default Pricelist - Go to Point of Sale / Products / Pricelists - Open PL - Set a company (must be diffe
Original PR description
This commit ensure the pricelists are properly configured before launching a pos session. Steps to reproduce: - Have a V13 with point_of_sale - Have minimum 2 companies A & B - Select both companies…
This commit ensure the pricelists are properly configured before launching a pos session.
Steps to reproduce:
- Have a V13 with point_of_sale
- Have minimum 2 companies A & B
- Select both companies in the company selector
- Go to Settings / General Settings
- Point of Sale
- Check Pricelists
- Go to Point of Sale
- Open a pos.config PC
- Set a Pricelist PL as Default Pricelist
- Go to Point of Sale / Products / Pricelists
- Open PL
- Set a company (must be different than PC)
- Go to Point of Sale
- Click "New session" on PC
--> Traceback
In V13, the traceback shows as "Traceback not available"
As from V14, the traceback is shown properly
A variant would be to start the session before changing
the pricelist company then click on "Resume" on PC
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#78724
Forward-Port-Of: odoo/odoo#78713Steps to reproduce: - Install website_sale module - Enable discount and advanced pricelist in settings - Create product with sale price 0$ and set a website in eCommerce + publish the product - Create pricelist PPP with Discount Policy as "Show public price & discount to the customer" and selectable in the website - Go to the product and set an extra price of 10$ for the new pricelist - Go to the product in the eshop and select the pricelist PPP - Add the product
Original PR description
Steps to reproduce:
- Install website_sale module
- Enable discount and advanced pricelist in settings
- Create product with sale price 0$ and set a website in
eCommerce + publish the product
- Create pricelist PPP with Discount Policy as
"Show public price & discount to the customer" and selectable in the website
- Go to the product and set an extra price of 10$ for the new pricelist
- Go to the product in the eshop and select the pricelist PPP
- Add the product to the shop cart
Issue:
The price displayed is 0$ instead of 10$.
Cause:
Since price_unit equal 0$, not possible to calculate the discount and
therefore using the 0$ value.
Solution:
Use price of pricelist in case 'discount_policy' is 'without_discount'
and price_unit equal 0$.
opw-2652192
Forward-Port-Of: odoo/odoo#78701
Forward-Port-Of: odoo/odoo#78570This commit intends to fix two strange bugs encountered while trying to push a new component into the systray menu: - MessagingMenuWidget and RtcActivityNoticeWidget were removing their parent node via DOM manipulations when attached in the DOM. This caused a crash when adding other items to the systray menu since the deleted nodes were actually managed by OWL. - The t-foreach directive in the navbar used indexes as the t-key, which led mapping items subsequently added to wrong templates. P
Original PR description
This commit intends to fix two strange bugs encountered while trying to push a new component into the systray menu: - MessagingMenuWidget and RtcActivityNoticeWidget were removing their parent node via DOM manipulations when attached in the DOM. This caused a crash when adding other items to the systray menu since the deleted nodes were actually managed by OWL. - The t-foreach directive in the navbar used indexes as the t-key, which led mapping items subsequently added to wrong templates. Previous PR: https://github.com/odoo/odoo/pull/78022 Forward-Port-Of: odoo/odoo#78572
With the release of Debian Bullseye and as the Odoo policy is to stick as close as possible to python3-* Debian packages versions, the time as come to adapt the requirements. Forward-Port-Of: odoo/odoo#78131
Original PR description
With the release of Debian Bullseye and as the Odoo policy is to stick as close as possible to python3-* Debian packages versions, the time as come to adapt the requirements. Forward-Port-Of: odoo/odoo#78131
Before this commit, When you try to edit the link then the link widget is removing 'btn-block' class from the class list of the link node. After this commit, the link widget will allow using 'btn-block' class. Forward-Port-Of: odoo/odoo#78511
Original PR description
Before this commit, When you try to edit the link then the link widget is removing 'btn-block' class from the class list of the link node. After this commit, the link widget will allow using 'btn-block' class. Forward-Port-Of: odoo/odoo#78511
when a message or logenote with attachment(s) is edited attachment gets removed even if user does not want to delete attachment. after this commit, editing message text will update only message and attachment will not be removed. attachment will be deleted only when user wants to delete it https://drive.google.com/file/d/1ILmaP3DpbI9YvyUYG2h2L5lI1Ld_zrDT/view?usp=sharing -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/od
Original PR description
when a message or logenote with attachment(s) is edited attachment gets removed even if user does not want to delete attachment. after this commit, editing message text will update only message and attachment will not be removed. attachment will be deleted only when user wants to delete it https://drive.google.com/file/d/1ILmaP3DpbI9YvyUYG2h2L5lI1Ld_zrDT/view?usp=sharing -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78603
See https://github.com/odoo/odoo/pull/78572 Forward-Port-Of: odoo/enterprise#21818
Original PR description
See https://github.com/odoo/odoo/pull/78572 Forward-Port-Of: odoo/enterprise#21818
Because we are using the Form simulation tool to fill the invoice, it will check by default that the required fields of the form view are all filled. This is annoying as the OCR will leave these blank and the user will get a traceback. The issue is solved by removing the check of required fields before saving the form. Forward-Port-Of: odoo/enterprise#21677 Forward-Port-Of: odoo/enterprise#21607
Original PR description
Because we are using the Form simulation tool to fill the invoice, it will check by default that the required fields of the form view are all filled. This is annoying as the OCR will leave these blank and the user will get a traceback. The issue is solved by removing the check of required fields before saving the form. Forward-Port-Of: odoo/enterprise#21677 Forward-Port-Of: odoo/enterprise#21607
It seems there were some conflicts badly resolved during forward port between these commits: 1f325e84740aac6a686cd6df4cf9b9ff5d4edc8e 84e3aa2217079230e436d7f4d1a691c38665593f The key `analytic` was never set anymore as it was not part of the fix of the original fix because the original fix was never merged: https://github.com/odoo/enterprise/pull/18559#issuecomment-849491344 [task-2671742](https://www.odoo.com/web#id=2671742&model=project.task) Forward-Port-Of: odoo/enterprise#21797
Original PR description
It seems there were some conflicts badly resolved during forward port between these commits: 1f325e84740aac6a686cd6df4cf9b9ff5d4edc8e 84e3aa2217079230e436d7f4d1a691c38665593f The key `analytic` was never set anymore as it was not part of the fix of the original fix because the original fix was never merged: https://github.com/odoo/enterprise/pull/18559#issuecomment-849491344 [task-2671742](https://www.odoo.com/web#id=2671742&model=project.task) Forward-Port-Of: odoo/enterprise#21797
The purpose of this commit is to improve the UX - renamed the action 'By Sales Order' into 'Schedule by Sales Order' of sale order planning. - Added 'Assignees' field from the map view popover - removed 'Assigned To' field from the map view popover TaskID-2646204 Forward-Port-Of: odoo/enterprise#20949
Original PR description
The purpose of this commit is to improve the UX - renamed the action 'By Sales Order' into 'Schedule by Sales Order' of sale order planning. - Added 'Assignees' field from the map view popover - removed 'Assigned To' field from the map view popover TaskID-2646204 Forward-Port-Of: odoo/enterprise#20949
- Have a company in MX with main currency MXN - Activate Multicurrency (i.e. USD), with rates: * yesterday: 0.055 * today: 0.05 - Have an invoice with date yesterday, total 10000 in USD - Confirm, validate CFDI - Register a partial payment of 100000 MXN (keep the invoice open) - Go to the payment, send CFDI User will get the error Code 301: """ Message : Error en complemento Recepción de Pagos. [Error #CRP206] La suma de los valores registrados en el campo ImpPagado de los a
Original PR description
- Have a company in MX with main currency MXN
- Activate Multicurrency (i.e. USD), with rates:
* yesterday: 0.055
* today: 0.05
- Have an invoice with date yesterday, total 10000 in USD
- Confirm, validate CFDI
- Register a partial payment of 100000 MXN (keep the invoice open)
- Go to the payment, send CFDI
User will get the error Code 301:
"""
Message : Error en complemento Recepción de Pagos. [Error #CRP206] La
suma de los valores registrados en el campo ImpPagado de los apartados
DoctoRelacionado no es menor o igual que el valor del campo Monto.
"""
The error occur because the field holding the paid amount reported on
the CFDI is different from the actual paid amount in foreign currency
opw-2623566
Forward-Port-Of: odoo/enterprise#21675
Forward-Port-Of: odoo/enterprise#20448A few fixes and a bunch of changes for the Inventory Adjustment though the Barcode Application. See commits for more details. task-2632818 Forward-Port-Of: odoo/enterprise#20985
Original PR description
A few fixes and a bunch of changes for the Inventory Adjustment though the Barcode Application. See commits for more details. task-2632818 Forward-Port-Of: odoo/enterprise#20985