Daily updates from Odoo
Navigate
Branch
Wednesday, February 5, 2020
40 changes
Security fixes and vulnerability patches
This change makes temporary wizard screens follow the same access control checks as regular business records. It reduces the risk that users can misuse setup or processing wizards by entering chosen values outside their intended permissions, while also hiding actions that users cannot use.
Original PR description
Before this commit, models with the `_transient` flag were ignored in ir.model.access verifications. Only an implicit ir.rule with the domain (create_uid=user.id) was applied to avoid most side effects. The problem is that, often, the security does not lie in side-effects of abusing of somebody else's wizard record but in the fact that the wizard methods blindly trust only the right users are creating these records. Too often, too many sudo were used and creating wizard with chosen values could lead to an abuse scenario. Instead, explicitly require the developer to declare security rules the same way as on any other model. Task-id: 1863044 Pad: https://pad.odoo.com/p/r.c1befa51103ed3b955a427971eb19719
This update adds missing permission rules for many temporary workflows, such as creating tickets, requesting signatures, generating payroll or contract links, importing statements, and managing stock or delivery actions. It helps ensure employees and managers can perform the right actions while keeping restricted operations limited to the appropriate roles.
Original PR description
Follow up of odoo/odoo#43306
New functionality added to Odoo
Adds a shared timer capability that can be used across Odoo apps, starting with timesheets and helpdesk tickets. This lets each user track time independently on records and gives teams a more consistent way to start, pause, resume, and stop work timers.
Original PR description
1/ timer: New mixin to record time on models Purpose The timer mechanism is already existing on timesheet. We would like to introduce it on helpdesk.ticket too, and probably on other models…
1/ timer: New mixin to record time on models
Purpose
The timer mechanism is already existing on timesheet.
We would like to introduce it on helpdesk.ticket too, and
probably on other models afterward.
On the other hand, only one timer can be launched on a single
timesheet currently, shared amongst the different users.
This commit introduced a new mixin on which
- Each user can launch a timer on each record of the models
inheriting the mixin.
- Launching a new timer on a record pauses the timer of the
user that could be already running.
- The mixin brings methods to start/stop/pause/resume the
timer, that could be overridden to implement a specific
behavior for the related model, for example create a
timesheet entry.
2/ test_timer: Add test module for the timer mixin
Purpose
As testing the mixin requires to create a new model,
we prefered to create another module.
3/ hr_timesheet: Adapt timer with new timer mixin
Purpose
Now that we have a new timer mixin that offers more possibilities
than what was currently implemented, we can reuse it in the timesheet
management module.
4/ timesheet_grid: Adapt timer buttons to new mixin
Purpose
The timesheets now uses an improved version of the timer,
using a new mixin.
Adapt the code accordingly.
5/ helpdesk_timesheet: Use timer mixin on helpdesk tickets
Purpose
Now that we have a new timer mixin that offers more possibilities
than what was currently implemented, we can reuse it in the helpdesk
management module.
TaskID: 2149450Sales orders can now use the salesperson’s default warehouse, helping businesses with multiple shops, vans, or stock locations track inventory more accurately. If no user-specific warehouse is set, the system keeps the existing default selection behavior.
Original PR description
Purpose ====== Our current integration between FSM and Stock works well for basic flows, but quickly shows limitations. We don't handle warehouse by employee. Use-case: each worker has a dedicated…
Purpose ====== Our current integration between FSM and Stock works well for basic flows, but quickly shows limitations. We don't handle warehouse by employee. Use-case: each worker has a dedicated van with a dedicated stock. I want to track the material used for each intervention to make sure that nothing is stolen. + This is also useful in usecases outside of FSM. Example: I have 3 shops (= 3 warehouses), each employee works in a different shop, the default warehouse set on the Sales Order should be the default warehouse of the salesperson. So this should be done sale_stock (and not in FSM) Specifications =========== Add a 'Default Warehouse' field on the user only visible if : - sale_stock is installed - the 'multi-warehouses' feature is enabled - domain should only include warehouses which belong to a company the user has access to - not required The field should be editable by a user on his own profile and by the admin on all users. When creating a FSM task from scratch, adding some products creates a SO, the warehouse on the SO should be the default warehouse of the user set on the FSM task. On SO creation, set the 'default warehouse' selected on the user assigned to the SO. If there isn't any 'default warehouse' set on the user, fallback on the current behavior (warehouse with lowest sequence) The field on the res.user should be a property field to allow multicompany usage. Task : 2166382
Adds a reusable timer capability so employees can track time more consistently across timesheets and helpdesk tickets. Each user can run their own timer per record, making support and timesheet work easier to measure without blocking others.
Original PR description
1/ timer: New mixin to record time on models Purpose The timer mechanism is already existing on timesheet. We would like to introduce it on helpdesk.ticket too, and probably on other models…
1/ timer: New mixin to record time on models
Purpose
The timer mechanism is already existing on timesheet.
We would like to introduce it on helpdesk.ticket too, and
probably on other models afterward.
On the other hand, only one timer can be launched on a single
timesheet currently, shared amongst the different users.
This commit introduced a new mixin on which
- Each user can launch a timer on each record of the models
inheriting the mixin.
- Launching a new timer on a record pauses the timer of the
user that could be already running.
- The mixin brings methods to start/stop/pause/resume the
timer, that could be overridden to implement a specific
behavior for the related model, for example create a
timesheet entry.
2/ test_timer: Add test module for the timer mixin
Purpose
As testing the mixin requires to create a new model,
we prefered to create another module.
3/ hr_timesheet: Adapt timer with new timer mixin
Purpose
Now that we have a new timer mixin that offers more possibilities
than what was currently implemented, we can reuse it in the timesheet
management module.
4/ timesheet_grid: Adapt timer buttons to new mixin
Purpose
The timesheets now uses an improved version of the timer,
using a new mixin.
Adapt the code accordingly.
5/ helpdesk_timesheet: Use timer mixin on helpdesk tickets
Purpose
Now that we have a new timer mixin that offers more possibilities
than what was currently implemented, we can reuse it in the helpdesk
management module.
TaskID: 2149450Enhancements to existing features
This update makes it easier for users to find production stock locations and configure the right interim accounts on them. It also improves the product category accounting form by placing key valuation journal and account fields more prominently.
Original PR description
Description of the issue/feature this PR addresses: Ease encoding of interim accounts on locations Current behavior before PR: Desired behavior after PR is merged: Task : 2161057 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Record change logs in Mail are now generated later in the save process, so multiple edits can be combined into one clearer update. The improvement also captures changes to stored calculated fields, giving users a more complete and reliable activity history across affected apps.
Original PR description
Improve tracking by generating the tracking message at flush. Also implement the tracking for stored computed fields.
This change makes an internal email-related test more reliable by clearing pending bus messages before checking results. It helps avoid false test failures caused by leftover test data, supporting smoother development and release validation.
Original PR description
The bus was expected empty at the start of the test, but it might not always be the case, so a reset has been added before the assertion. This is similar to what was already done to most of the other `assertBus`. Part of task-2178641
Odoo now prevents reducing the number of decimal places for a currency once accounting entries already exist, avoiding rounding changes that could affect posted financial data. Users are also warned when increasing decimal places so they understand the accounting impact before proceeding.
Original PR description
If accounting entries have already been generated by this currency, we now forbid setting it a lesser number of decimal places (so, higher rounding factor). We also display a warning when increasing the number of decimal places, to make sure the user is aware of the impact it'll have.
The sales product configurator has been aligned with list-based product selection behavior. This means future customizations or changes to list product fields will also apply consistently to the configurator, reducing inconsistencies for users working in sales order lines.
Original PR description
The product configurator widget is only actually used in lists, does it make sense to let it extend from bare `FieldMany2One`? **Description of the issue/feature this PR addresses** Product configurator widget does not inherit specific behaviors from the widget `ListFieldMany2One`, so changes to `ListFieldMany2One` widget do not affect product configurator, see for instance https://github.com/OCA/web/pull/1438#issuecomment-555636435. **Current behavior before PR** Overriding `ListFieldMany2One` widget does not affect product configurator widget. **Desired behavior after PR is merged** Overriding `ListFieldMany2One` widget does affect product configurator widget. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website form builder now uses the left-side options panel, making form editing more consistent with other website editing tools. This improves the editing experience for teams configuring helpdesk and website forms without changing the end-user form behavior.
Original PR description
* = website_studio The form builder is now using the left panel option system.
This update improves the reliability of field change tracking across several Odoo Enterprise apps. It fixes edge cases that could affect manufacturing maintenance updates, field service billing settings, and holiday work-entry performance tests, helping ensure data is saved and reported consistently.
Original PR description
Counterpart of odoo/odoo#41554.
Sales orders created from field service tasks now use the warehouse assigned to the responsible user, such as a technician's van or an employee's shop. This helps businesses track stock usage more accurately by employee location while keeping the existing default behavior when no user warehouse is set.
Original PR description
Purpose ====== Our current integration between FSM and Stock works well for basic flows, but quickly shows limitations. We don't handle warehouse by employee. Use-case: each worker has a dedicated…
Purpose ====== Our current integration between FSM and Stock works well for basic flows, but quickly shows limitations. We don't handle warehouse by employee. Use-case: each worker has a dedicated van with a dedicated stock. I want to track the material used for each intervention to make sure that nothing is stolen. + This is also useful in usecases outside of FSM. Example: I have 3 shops (= 3 warehouses), each employee works in a different shop, the default warehouse set on the Sales Order should be the default warehouse of the salesperson. So this should be done sale_stock (and not in FSM) Specifications =========== Add a 'Default Warehouse' field on the user only visible if : - sale_stock is installed - the 'multi-warehouses' feature is enabled - domain should only include warehouses which belong to a company the user has access to - not required The field should be editable by a user on his own profile and by the admin on all users. When creating a FSM task from scratch, adding some products creates a SO, the warehouse on the SO should be the default warehouse of the user set on the FSM task. On SO creation, set the 'default warehouse' selected on the user assigned to the SO. If there isn't any 'default warehouse' set on the user, fallback on the current behavior (warehouse with lowest sequence) The field on the res.user should be a property field to allow multicompany usage. Related to : https://github.com/odoo/odoo/pull/44257 Task : 2166382
Accounting-related numbering has been aligned with the latest core system changes after journal-specific sequences were removed. This keeps financial documents and related payroll, subscription, reporting, and follow-up flows consistent with the new five-digit default numbering format.
Original PR description
Task [2146469](https://www.odoo.com/web?debug=1#id=2146469&action=333&active_id=967&model=project.task&view_type=form&menu_id=4720) The sequences of journals have been removed in community. * The field sequence_id of account.journal has been removed * Sequences now have a padding of 5 digits by defa
This update removes an outdated view override that was keeping older, harder-to-maintain button behavior in field service sales reports. Users benefit from more consistent report actions across field service screens, while the change reduces maintenance risk.
Original PR description
On #6918 we removed the horrible attrs on the different buttons on fsm views. However it seems to have missed a bunch o' the bits e.g. the unreadable attr domain on action_send_report is replaced by a much simpler one in industry_fsm_report but then industry_fsm_sale_report still overwrites everything with the same old garbage. See: https://github.com/odoo/enterprise/blob/f8fb18ec3dc7dd8d5fffa22cd9cd6e2be74e5391/industry_fsm_sale_report/views/project_views.xml
Portal users can now send messages directly without the page refreshing. This makes conversations smoother and helps users continue their work without losing context or waiting for a full reload.
Original PR description
Description of the issue/feature this PR addresses: Task-ID: https://www.odoo.com/web?#id=2054662&action=327&model=project.task&view_type=form&menu_id=4720
Resolved issues and error corrections
This update fixes wording mistakes where purchase order screens incorrectly referenced sales orders. It improves clarity for users working with the purchase product matrix without changing business processes.
Original PR description
Some typos. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website editor now properly recognizes negative numbers in its left-side settings panel. This prevents valid negative values from appearing as blank fields, reducing confusion when editing layouts or styles.
Original PR description
A negative value, even if legit, was not understood by the editor and induced empty inputs in the left panel.
This fixes the user interface for advanced pricelist rules in the Product area. It helps users manage pricing rules more clearly and reduces confusion when configuring product prices.
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website widgets now load their supporting files with the right website context, so website-specific styling and behavior are preserved. This prevents assets from being loaded without the current website ID, reducing broken or inconsistent website editor experiences.
Original PR description
*: web Before this commit, when a widget declared assets to lazy load through the assetLibs key, the asset was loaded through a context-less call to the server through the base `rpc` function. This caused problems in website: the website ID was not given to the called route and the loaded assets were then stripped of their specific-website parts. This commit solves the problem by allowing the `loadLibs` and `loadAsset` functions to receive an extra argument: an extra `context` to use for the actual call to the server. The method is now available in the ajax service, so that website can add its custom context automatically, the same way it does it for normal `_rpc` calls.
The timesheet grid now returns an empty list when there are no columns to add, instead of returning nothing. This prevents a crash in the timesheet interface and keeps the user experience stable in edge cases.
Original PR description
The method `_searchColToAddButton` currently returns an Array or `null` if the array is empty. It should always consitently return an array. Currently, the code calling the method crashes if it gets back `null`. It's expecting an array and iterates over it. `null` is not iterable.
This update corrects a sales subscription dashboard view so users see the intended reporting layout. It also removes an unused purchase report view customization that had no business impact, reducing maintenance noise.
This update adds an extra wait step after selecting documents in automated tests. It helps prevent occasional false test failures, supporting more stable releases without changing user-facing behavior.
Original PR description
After the fix of #7911, some tests could still fail, this commits makes sure that we wait after each document selection.
Code cleanup and technical improvements
Planning now creates recurring schedule slots in batches instead of one at a time. This reduces processing time for automated schedule generation by roughly 30-40%, helping larger planning setups run more efficiently.
Original PR description
This commit changes the `planning.slot` create method from create_single to create_multi. Quick benchmark: - cron configured to generate 6 months (this is the default value) - 3 companies with - 4 recurring slots/day - 7 days/week - 4 employees Run the cron: it generates 2688 slots per company The performance improves by 30 to 40%. The execution time goes from ~8.8s to ~5.5s.
Miscellaneous changes
PURPOSE: Fix traceback when creating an invoice for sale order with an empty product. SPECIFICATIONS: Currently create an SO without any products and confirm it.Then create invoice select down payment option and write the amount then after click on create invoice so the traceback is generated. Fixes the traceback by setting the value of sequence in dictionary with and operator. LINKS PR #44491 Task 2181464 Forward-Port-Of: odoo/odoo#44491
Original PR description
PURPOSE: Fix traceback when creating an invoice for sale order with an empty product. SPECIFICATIONS: Currently create an SO without any products and confirm it.Then create invoice select down payment option and write the amount then after click on create invoice so the traceback is generated. Fixes the traceback by setting the value of sequence in dictionary with and operator. LINKS PR #44491 Task 2181464 Forward-Port-Of: odoo/odoo#44491
Steps to reproduce the bug: - Give 'Administrator' rights for the Sales app and no rights for the Point of Sales app to the demo user - Try to access CRM > Sales > Team Pipelines as Marc Demo Bug: Access Rights error on pos.session opw:2184032 Forward-Port-Of: odoo/odoo#44618
Original PR description
Steps to reproduce the bug: - Give 'Administrator' rights for the Sales app and no rights for the Point of Sales app to the demo user - Try to access CRM > Sales > Team Pipelines as Marc Demo Bug: Access Rights error on pos.session opw:2184032 Forward-Port-Of: odoo/odoo#44618
* Content reordering * Main attributes highlight on page beginning * Little introduction to the page and concept of "views" * UI fixes/improvements * little content modification in gantt view for clearer create/edit/plan attributes #### Side doc work * orm page finetuning -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44516 Forward-Port-Of: odoo/odoo#43782
Original PR description
* Content reordering * Main attributes highlight on page beginning * Little introduction to the page and concept of "views" * UI fixes/improvements * little content modification in gantt view for clearer create/edit/plan attributes #### Side doc work * orm page finetuning -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44516 Forward-Port-Of: odoo/odoo#43782
pass move type to a journal for filtration but it is removed by this commit https://github.com/odoo/odoo/commit/a9b762870651e607b244d8fd5681a9f3557cc0e9#diff-59b30a3c3997659843dcc916225f508aL36 so no more in use -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44538
Original PR description
pass move type to a journal for filtration but it is removed by this commit https://github.com/odoo/odoo/commit/a9b762870651e607b244d8fd5681a9f3557cc0e9#diff-59b30a3c3997659843dcc916225f508aL36 so no more in use -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44538
### Issue - Install eLearning - Delete a rating - Go to the course page, review tab Only the stars disappeared. ### Cause Review = rating + message, the rating is the stars and publisher_comment So this is normal if the review is not completely deleted ### Solution Seen with SBU and he said that the message should be deleted too. **OPW-2181568** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.c
Original PR description
### Issue
- Install eLearning
- Delete a rating
- Go to the course page, review tab
Only the stars disappeared.
### Cause
Review = rating + message, the rating is the stars and
publisher_comment
So this is normal if the review is not completely deleted
### Solution
Seen with SBU and he said that the message should be deleted
too.
**OPW-2181568**
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#44284- Create a partner which is a company - Add a contact - Create an invoice for the contact, post it Both the contact and the company are set as followers of the invoice. Only the contact should be, there is no reason to make the company follower too. opw-2179084 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 F
Original PR description
- Create a partner which is a company - Add a contact - Create an invoice for the contact, post it Both the contact and the company are set as followers of the invoice. Only the contact should be, there is no reason to make the company follower too. opw-2179084 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#44474
Since you can only reconcile entries from the same partner, you must always use the commercial partner when creating some journal items. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44555
Original PR description
Since you can only reconcile entries from the same partner, you must always use the commercial partner when creating some journal items. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44555
The bank_ids returned by partner autocomplete needed to be formatted with the xtomany syntax. opw-2188676 Forward-Port-Of: odoo/enterprise#8129
Original PR description
The bank_ids returned by partner autocomplete needed to be formatted with the xtomany syntax. opw-2188676 Forward-Port-Of: odoo/enterprise#8129
- Create a group of taxes: 20% price included & 10% price excluded - Create an invoice line of 1200.0. - Check the Tax Report => The Net base amount is missing because the group of taxes is no longer expanded since the merge of account.invoice with account.move. Forward-Port-Of: odoo/enterprise#8060
Original PR description
- Create a group of taxes: 20% price included & 10% price excluded - Create an invoice line of 1200.0. - Check the Tax Report => The Net base amount is missing because the group of taxes is no longer expanded since the merge of account.invoice with account.move. Forward-Port-Of: odoo/enterprise#8060
Steps to reproduce the bug: - Let's consider that Odoo is in multi company with two companies C1 and C2 - Configure Document Layout from General Settings for C1 and C2 - Let's consider that the default company of the current user U is C1 - Log U in C2 (allowed_company_ids) - Try to print the letter of a followup report Bug: The layout from C1 was printed in the letter instead of the layout of C2 opw:2182223 Forward-Port-Of: odoo/enterprise#8138
Original PR description
Steps to reproduce the bug: - Let's consider that Odoo is in multi company with two companies C1 and C2 - Configure Document Layout from General Settings for C1 and C2 - Let's consider that the default company of the current user U is C1 - Log U in C2 (allowed_company_ids) - Try to print the letter of a followup report Bug: The layout from C1 was printed in the letter instead of the layout of C2 opw:2182223 Forward-Port-Of: odoo/enterprise#8138
- On a job application, generate an offer link - Fill in the offer link, change the representation fees - Go to the signature step - Click on the 'Back' button of the browser The representation fees chosen previously are selected, but the value recorded is the default value. We trigger the change on the representation fees manually to trigger the appropriate recomputation. opw-2185171 Forward-Port-Of: odoo/enterprise#8075
Original PR description
- On a job application, generate an offer link - Fill in the offer link, change the representation fees - Go to the signature step - Click on the 'Back' button of the browser The representation fees chosen previously are selected, but the value recorded is the default value. We trigger the change on the representation fees manually to trigger the appropriate recomputation. opw-2185171 Forward-Port-Of: odoo/enterprise#8075
In the next case: 1. Create an entry in January for 100 MXN (Supplier invoice) 2. Get the Mexican Trial Balance, the result is correct Balance inicial Debe Haber Total $ 0.00 $ 0.00 $ 500.00 $ -500.00 3. Now, get the Trial Balance for February, and must have this values Balance inicial Debe Haber Total $ -500.00 $ 0.00 $ 0.00 $ -500.00 Without this fix, the Debit/Credit in February are incorrect Balance inicial Debe Haber Total $ -5
Original PR description
In the next case: 1. Create an entry in January for 100 MXN (Supplier invoice) 2. Get the Mexican Trial Balance, the result is correct Balance inicial Debe Haber Total $ 0.00 $ 0.00 $ 500.00 $ -500.00 3. Now, get the Trial Balance for February, and must have this values Balance inicial Debe Haber Total $ -500.00 $ 0.00 $ 0.00 $ -500.00 Without this fix, the Debit/Credit in February are incorrect Balance inicial Debe Haber Total $ -500.00 $ 0.00 $ 500.00 $ -1,000.00 Because the credit is taking the previous amount opw#2181092 Forward-Port-Of: odoo/enterprise#8092
For Swiss files, in case a postal account is to receive the payment, local instrument CH01 must be specified, and ISR reference passed as a structured reference, instead of unstructured. Forward-Port-Of: odoo/enterprise#7966
Original PR description
For Swiss files, in case a postal account is to receive the payment, local instrument CH01 must be specified, and ISR reference passed as a structured reference, instead of unstructured. Forward-Port-Of: odoo/enterprise#7966
- In the 'Operation Type' 'Manufacturing', set 'Create New Lots/Serial Numbers for Components' to False. - Create Products A1 & A2 - Create a BoM for A1: 2 units of A2 Set a routing, e.g. 'Primary Assembly' - Make some stock of A2 for lot XXXX - Create a MO for A1 - Lauch the workorder processing - Instead of lot XXXX, scan lot YYYY (with the barcode scanner) Nothing prevents from creating a new lot, while a UserError should be raised. This is because `active_mo_id` is not
Original PR description
- In the 'Operation Type' 'Manufacturing', set 'Create New Lots/Serial Numbers for Components' to False. - Create Products A1 & A2 - Create a BoM for A1: 2 units of A2 Set a routing, e.g. 'Primary Assembly' - Make some stock of A2 for lot XXXX - Create a MO for A1 - Lauch the workorder processing - Instead of lot XXXX, scan lot YYYY (with the barcode scanner) Nothing prevents from creating a new lot, while a UserError should be raised. This is because `active_mo_id` is not in the context, therefore the `_check_create` doesn't work. We add the context key in the barcode method handler. opw-2179652 Forward-Port-Of: odoo/enterprise#8139
[FIX] project_timesheet_forecast_sale: avoid division by zero If you plan somebody in a project, a small-time, less than a day, the working_days_count field will be zero (https://github.com/odoo/enterprise/blob/13.0/planning/models/planning.py#L131) If this user don't have a planning bigger than a day in the project, when opening the overview a division by zero error will be raised. opw-217834 -------------------------------------------------------------------------------------------
Original PR description
[FIX] project_timesheet_forecast_sale: avoid division by zero If you plan somebody in a project, a small-time, less than a day, the working_days_count field will be zero (https://github.com/odoo/enterprise/blob/13.0/planning/models/planning.py#L131) If this user don't have a planning bigger than a day in the project, when opening the overview a division by zero error will be raised. opw-217834 --------------------------------------------------------------------------------------------------------------- [FIX] planning: working days shouldn't be zero Before this commit, the working days count was only filled if the planning number of hours was bigger than the hours working day. If an employee is planned to work two hours in the task, it should be one working day and not zero as it's the case for the moment. Now, the working days are rounded up. opw-2178341 Forward-Port-Of: odoo/enterprise#8134
### Issue - Install Subscriptions - Subscriptions > Reports > Revenue KPI - Click on any graph The second row of the layout is broken the elements should be on one line ### Cause We use col-lg-3 without row ### Solution Add the row (and a container to avoid negative margin issues) **OPW-2188623** Forward-Port-Of: odoo/enterprise#8136
Original PR description
### Issue - Install Subscriptions - Subscriptions > Reports > Revenue KPI - Click on any graph The second row of the layout is broken the elements should be on one line ### Cause We use col-lg-3 without row ### Solution Add the row (and a container to avoid negative margin issues) **OPW-2188623** Forward-Port-Of: odoo/enterprise#8136