Daily updates from Odoo
Wednesday, February 28, 2024
28 changes · master
Resolved issues and error corrections
Fixed an issue where copying a task item in the Gantt timeline could fail after recent batch duplication changes. Users can now duplicate task timeline items reliably, while scheduling warnings continue to appear only when relevant.
Original PR description
Before this commit, since the recent changes to allow the duplication in batch, the duplication of a pill in task gantt view no longer works and raised a traceback. The reason is because the copy will now return an array and so the `openPlanDialogCallback` function will do a for each on that array to display eventual warnings, that override is in fact only when smart task scheduling is called and not for the other actions (copy, reschedule, etc). This commit checks if the result given in parameter for `openPlanDialogCallback` is not falsy and not an array before doing a for each on the object to display the eventual warnings to display.
Fixed an issue that could block moving an applicant to the first recruitment stage when the applicant was not linked to a job application. This helps recruitment workflows continue smoothly without template-related errors.
Original PR description
With this commit, an applicant without a job's applicantion can be moved to stage 1 without template issue. task : 3681692
Code cleanup and technical improvements
This update refreshes the internal automation used to test guided workflows across several business apps. It should not change day-to-day user behavior, but it helps keep the platform easier to maintain and aligned with modern browser standards.
Original PR description
In this commit, $anchor jQuery element in tour_compiler (used in run function in stepTour) is replaced by anchor native element. task~3600484 https://github.com/odoo/odoo/pull/155349
The point of sale apps now share common asset bundles instead of each defining many of the same resources separately. This reduces duplication and should make future maintenance and testing of these screens more consistent.
Original PR description
The pos ecosystem consists of multiple owl apps. The assets that
these apps are used are in a large part the same.
In this commit we create a generic assets bundle: `pos.simple_app`
that contains all the assets that a simple owl app might need.
We alse create an assets bundle called `pos.simple_tests` that includes
the assets neede for running tours.
https://github.com/odoo/odoo/pull/151316Spreadsheet pivots now use stable unique identifiers and the related spreadsheet code has been aligned with updated data handling. This reduces the risk of mismatched pivot references in documents and helps keep spreadsheet features consistent after platform changes.
Original PR description
This commit is the counter part of https://github.com/odoo/odoo/pull/155064. It updates the code to the new ids. Part of 3636089
Miscellaneous changes
Forward-Port-Of: odoo/enterprise#57575
Original PR description
Forward-Port-Of: odoo/enterprise#57575
**Current behavior:** Given a portal preview of a recurring sale order with an order line (for a recurring product) and a distinct optional product which is also recurring, if the optional product is added to the cart and then the order is brought back into the editor view, should the recurring plan for the order be changed, the optional product (which is now added to the order) will not have its price adjusted accordingly. **Expected behavior:** The optional product that has been add
Original PR description
**Current behavior:** Given a portal preview of a recurring sale order with an order line (for a recurring product) and a distinct optional product which is also recurring, if the optional product is…
**Current behavior:**
Given a portal preview of a recurring sale order with an order
line (for a recurring product) and a distinct optional product
which is also recurring, if the optional product is added to
the cart and then the order is brought back into the editor
view, should the recurring plan for the order be changed, the
optional product (which is now added to the order) will not
have its price adjusted accordingly.
**Expected behavior:**
The optional product that has been added to the order will have
its price adjusted to match the recurring plan selected for the
sale order.
**Steps to reproduce:**
1. Create two distinct recurring products and assign them
subscription prices for the same recurring plan timetable
2. Create a new sale order, adding one product to the order and
the other to the optional products tab
3. Preview the sale order and add the optional product to the
cart, then return to the editor view
4. Select a new recurring plan for the sale order where each
product has a different set price than the one which is
currently displayed on the order lines
5. The product which was initially added in an order line will
have its price adjusted accordingly, while the product
which was added from the optional products section will
remain static.
**Cause of the issue:**
In sale_management, the _compute_price_unit() method is
extended such that it filters SOLs which have order options
associated with them.
**Fix:**
Override the filter method from sale_management so that lines
which are associated with recurring products will end up having
their prices updated.
opw-3698798
Forward-Port-Of: odoo/enterprise#55710Add and use a default resource calendar encompassing every hours of every days. This allows to take into account leaves for resource easily as we need a resource calendar for the computation. Indeed when the resource calendar was removed, the one set on the company was used in place which led to weird result for the end user as he didn't expect a working schedule after removing the one set on the resource. task-3562191 Forward-Port-Of: odoo/enterprise#57330 Forward-Port-Of: odoo/enterprise#5
Original PR description
Add and use a default resource calendar encompassing every hours of every days. This allows to take into account leaves for resource easily as we need a resource calendar for the computation. Indeed when the resource calendar was removed, the one set on the company was used in place which led to weird result for the end user as he didn't expect a working schedule after removing the one set on the resource. task-3562191 Forward-Port-Of: odoo/enterprise#57330 Forward-Port-Of: odoo/enterprise#56617
Task-3770997 ## Description: If the execution of the code is abruptly interrupted during an incoming call invitation (e.g. by closing the page), when the call is reopened in the softphone, the correspondence details of the call get stuck in the invitation view. This commit prevents this from happening by also checking for the presence of an actual session as a condition to display the call invitation view. ## How to reproduce: 1. Configure a database with VoIP in production mode 2. Rec
Original PR description
Task-3770997 ## Description: If the execution of the code is abruptly interrupted during an incoming call invitation (e.g. by closing the page), when the call is reopened in the softphone, the correspondence details of the call get stuck in the invitation view. This commit prevents this from happening by also checking for the presence of an actual session as a condition to display the call invitation view. ## How to reproduce: 1. Configure a database with VoIP in production mode 2. Receive an incoming call invitation and refresh the page without accepting/rejecting it 3. Re-open the call and notice that it's stuck on the invitation view :(( Forward-Port-Of: odoo/enterprise#57618
This PR fixes an issue about an overflow property being applied to all the modal across Odoo, while it should only affect a single module. During the design and UX improvements of `mrp_workorder`, Commit[1] introduced an overflow property on the `modal-body` in order to fix a layout on modal that have hidden content that is meant to be displayed when clicking on a button. While this line provided a fix for the issue, it was not scoped to the module and would then affects the whole bac
Original PR description
This PR fixes an issue about an overflow property being applied to all the modal across Odoo, while it should only affect a single module. During the design and UX improvements of `mrp_workorder`, Commit[1] introduced an overflow property on the `modal-body` in order to fix a layout on modal that have hidden content that is meant to be displayed when clicking on a button. While this line provided a fix for the issue, it was not scoped to the module and would then affects the whole back-end. To fix this issue, we add the property as a utility class on the specific modal. Commit[1]: [6f9b089](https://github.com/odoo/enterprise/pull/45032/commits/6f9b08984949d7c2bd0d7ee2c8d493cd05a1289e) ticket-3671725 Forward-Port-Of: odoo/enterprise#57536 Forward-Port-Of: odoo/enterprise#57420
This fixes an issue with the common test class in hr_payroll_holidays which is set to inherit from the invoicing test common class while the module does not depend on the account module. Forward-Port-Of: odoo/enterprise#57202
Original PR description
This fixes an issue with the common test class in hr_payroll_holidays which is set to inherit from the invoicing test common class while the module does not depend on the account module. Forward-Port-Of: odoo/enterprise#57202
Forward-Port-Of: odoo/enterprise#57613
Original PR description
Forward-Port-Of: odoo/enterprise#57613
Improve how the CODA journal is retrieved Community https://github.com/odoo/odoo/pull/155375 Forward-Port-Of: odoo/enterprise#57549 Forward-Port-Of: odoo/enterprise#57503
Original PR description
Improve how the CODA journal is retrieved Community https://github.com/odoo/odoo/pull/155375 Forward-Port-Of: odoo/enterprise#57549 Forward-Port-Of: odoo/enterprise#57503
When an incoming call is cancelled by the remote party, the current session is not properly cleared, causing Odoo to reject all subsequent calls, assuming the user is busy, since the previous session is still present. This commit fixes the problem by properly clearing the current session when a CANCEL message is received. Forward-Port-Of: odoo/enterprise#57525
Original PR description
When an incoming call is cancelled by the remote party, the current session is not properly cleared, causing Odoo to reject all subsequent calls, assuming the user is busy, since the previous session is still present. This commit fixes the problem by properly clearing the current session when a CANCEL message is received. Forward-Port-Of: odoo/enterprise#57525
Issue: When adding a new Calendar Item without a title, the item does not allocate the required space, causing it to appear slightly under the calendar item. Additionally, if any item is moved to the top of the calendar, it overlaps the title placeholder, preventing title modification. Steps to Reproduce: 1. Install Knowledge. 2. Create a new article and select 'Build an Item Calendar'. 3. Proceed without entering a title. 4. Type anything below the created Calendar and move it to
Original PR description
Issue: When adding a new Calendar Item without a title, the item does not allocate the required space, causing it to appear slightly under the calendar item. Additionally, if any item is moved to the top of the calendar, it overlaps the title placeholder, preventing title modification. Steps to Reproduce: 1. Install Knowledge. 2. Create a new article and select 'Build an Item Calendar'. 3. Proceed without entering a title. 4. Type anything below the created Calendar and move it to the top of it. Solution: Modify the 'onBuildItemCalendarBtnClick' function to utilize a "computed" title rather than directly using the name. This ensures that a placeholder title is always present, allowing for later deletion or modification. opw-3725805 Forward-Port-Of: odoo/enterprise#56423
The tag `document_tag_signature_request` is used by the `sign` endpoint, but it could be missing after an upgrade from <17 due to the `forcecreate=0` in the data file. Forward-Port-Of: odoo/enterprise#57324
Original PR description
The tag `document_tag_signature_request` is used by the `sign` endpoint, but it could be missing after an upgrade from <17 due to the `forcecreate=0` in the data file. Forward-Port-Of: odoo/enterprise#57324
Before this commit, the test test_add_non_searchable_field crashed in no-demo mode because an image was not set on a partner, and that had only an effect on a sanity check in the business code rather than an effect on the relavance of the test After this commit, the test doesn't crash in demo mode. runbot-error-57397 runbot-error-57430 runbot-error-57432 runbot-error-57822 runbot-error-58218 Forward-Port-Of: odoo/enterprise#57559
Original PR description
Before this commit, the test test_add_non_searchable_field crashed in no-demo mode because an image was not set on a partner, and that had only an effect on a sanity check in the business code rather than an effect on the relavance of the test After this commit, the test doesn't crash in demo mode. runbot-error-57397 runbot-error-57430 runbot-error-57432 runbot-error-57822 runbot-error-58218 Forward-Port-Of: odoo/enterprise#57559
Before this commit, the "Force Source Location scan" setting of the delivery picking type was always reset on "Mandatory Scan" every time the `stock_barcode` module was updated. This behavior is not wanted, if the user changes the setting, we don't want to update it again. Forward-Port-Of: odoo/enterprise#57499
Original PR description
Before this commit, the "Force Source Location scan" setting of the delivery picking type was always reset on "Mandatory Scan" every time the `stock_barcode` module was updated. This behavior is not wanted, if the user changes the setting, we don't want to update it again. Forward-Port-Of: odoo/enterprise#57499
Before this commit, the new class of tests for studio approvals crashed in without demo mode After this commit, it works as data used in the test have been adapted runbot-error-57997 runbot-error-57996 Forward-Port-Of: odoo/enterprise#57558
Original PR description
Before this commit, the new class of tests for studio approvals crashed in without demo mode After this commit, it works as data used in the test have been adapted runbot-error-57997 runbot-error-57996 Forward-Port-Of: odoo/enterprise#57558
TaskID: 3762935 Forward-Port-Of: odoo/enterprise#57432 Forward-Port-Of: odoo/enterprise#57365
Original PR description
TaskID: 3762935 Forward-Port-Of: odoo/enterprise#57432 Forward-Port-Of: odoo/enterprise#57365
**Steps** to reproduce: - Go to to the Helpdesk app - Under the "Customer Care" team, click on the number of open tickets (should be 6 if the runbot instance isn't modified) - While in the kanban view, remove the "Open" filter; notice how the view doesn't update to reflect the new query ### Investigation: - the domain associated with the action `'stage_id.fold', '=', True` filters out the tickets within folded stages (Solved, Canceled) opw-3719664 Forward-Port-Of: odoo/enterprise#5731
Original PR description
**Steps** to reproduce: - Go to to the Helpdesk app - Under the "Customer Care" team, click on the number of open tickets (should be 6 if the runbot instance isn't modified) - While in the kanban view, remove the "Open" filter; notice how the view doesn't update to reflect the new query ### Investigation: - the domain associated with the action `'stage_id.fold', '=', True` filters out the tickets within folded stages (Solved, Canceled) opw-3719664 Forward-Port-Of: odoo/enterprise#57315 Forward-Port-Of: odoo/enterprise#56453
Since commit d79ac56, invoices coming from the email alias were automatically sent to the OCR even when the automatic sending mode was disabled. The logic that decides whether or not the document should be automatically sent to the OCR was duplicated at multiple places, making this kind of error easy to make. This commit addresses the issue by introducing a new `_check_auto_extract_conditions` function that regroups all the necessary conditions that needs to be met for auto extraction. Ti
Original PR description
Since commit d79ac56, invoices coming from the email alias were automatically sent to the OCR even when the automatic sending mode was disabled. The logic that decides whether or not the document should be automatically sent to the OCR was duplicated at multiple places, making this kind of error easy to make. This commit addresses the issue by introducing a new `_check_auto_extract_conditions` function that regroups all the necessary conditions that needs to be met for auto extraction. Ticket #3708420 Forward-Port-Of: odoo/enterprise#57504
Steps to reproduce the issue: - Install `appointment_crm` module - Go to Calendar > Online Appointments - Open `Technical Demo` (for test purpose) - Go to `Options` tab and enable `Create Opportunities` - Click on `Preview` button - Schedule an appointment - Create another user that have only `Appointment / Administrator` access rights - Log in with the new user - Go to Calendar > Online Appointments - Open `Technical Demo` Issue: saas-16.2: Number of lead
Original PR description
Steps to reproduce the issue: - Install `appointment_crm` module - Go to Calendar > Online Appointments - Open `Technical Demo` (for test purpose) - Go to `Options` tab and enable `Create…
Steps to reproduce the issue:
- Install `appointment_crm` module
- Go to Calendar > Online Appointments
- Open `Technical Demo` (for test purpose)
- Go to `Options` tab and enable `Create Opportunities`
- Click on `Preview` button
- Schedule an appointment
- Create another user that have only `Appointment / Administrator` access rights
- Log in with the new user
- Go to Calendar > Online Appointments
- Open `Technical Demo`
Issue:
saas-16.2: Number of lead not displayed in stat button and raise an
access error when clicking on it. saas-16.3+: Access error is raised when trying to edit the appointment.
Cause:
Trying to display a stat button that exploit a field (`lead_count`)
that has a group declared in python (`group_sale_salesman`) while user
not being part of the group and group not declared on the stat button.
Solution:
Don't display button if not leads linked to the appointment.
Add group `group_sale_salesman` on stat button so it is not displayed
if user is not part of the group.
opw-3751444
Forward-Port-Of: odoo/enterprise#57488
Forward-Port-Of: odoo/enterprise#57299This commit(https://github.com/odoo/enterprise/commit/26fc172004d880f5e941c78cbdc18a29d2db5134) introduced a bug. This bug is caused when several lines that should be grouped in one line have different warnings. Before this fix, it generates several grouped lines instead of one. This is causing a javascript issue where the generic unique line id is duplicated (and it shouln't be the case). To fix it, this commit removes the group by in the `_build_query_group` function and accepts null val
Original PR description
This commit(https://github.com/odoo/enterprise/commit/26fc172004d880f5e941c78cbdc18a29d2db5134) introduced a bug. This bug is caused when several lines that should be grouped in one line have different warnings. Before this fix, it generates several grouped lines instead of one. This is causing a javascript issue where the generic unique line id is duplicated (and it shouln't be the case). To fix it, this commit removes the group by in the `_build_query_group` function and accepts null value in the `ARRAY_AGG`. When the code is checking if we have warnings, we remove the null values to only keep ids. opw-3751773 Forward-Port-Of: odoo/enterprise#57527
It is necessary to append the description "The due date should not be earlier than the invoice date. Please verify the invoice dates and payment terms." when the user receives error 10164. Task Adhoc side: 36216 Forward-Port-Of: odoo/enterprise#57157 Forward-Port-Of: odoo/enterprise#55901
Original PR description
It is necessary to append the description "The due date should not be earlier than the invoice date. Please verify the invoice dates and payment terms." when the user receives error 10164. Task Adhoc side: 36216 Forward-Port-Of: odoo/enterprise#57157 Forward-Port-Of: odoo/enterprise#55901
…fails Create a reconciliation model as follows: - Type: Rule to match invoices/bills - Match Invoice/bill with Label: False - Match Invoice/bill with Note: False - Match Invoice/bill with Reference: False - Partner is set: False Create an invoice for $900 and confirm it. Create a bank statement line for $900, with no partner set. Go to reconcile the bank statement line. Issue: The invoice is not automatically suggested This occurs because there is no check for the exact amount as
Original PR description
…fails Create a reconciliation model as follows: - Type: Rule to match invoices/bills - Match Invoice/bill with Label: False - Match Invoice/bill with Note: False - Match Invoice/bill with Reference: False - Partner is set: False Create an invoice for $900 and confirm it. Create a bank statement line for $900, with no partner set. Go to reconcile the bank statement line. Issue: The invoice is not automatically suggested This occurs because there is no check for the exact amount as in previous version opw-3648260 X-original-commit: 2de5df7 Forward-Port-Of: odoo/enterprise#57143
Before this commit, when the shift has the following planned dates: - start date: 2024-02-02 16:00:00 - end date: 2024-03-02 01:00:00 The shift is displayed in one day in the gantt view, the reason is because the gantt view truncates the date if between the date of the end date and the end date there is less than 3 hours than the pill will not be displayed in that day (same logic for the date of the start date and the start date) and will only be displayed in the other days, in that example, t
Original PR description
Before this commit, when the shift has the following planned dates: - start date: 2024-02-02 16:00:00 - end date: 2024-03-02 01:00:00 The shift is displayed in one day in the gantt view, the reason is because the gantt view truncates the date if between the date of the end date and the end date there is less than 3 hours than the pill will not be displayed in that day (same logic for the date of the start date and the start date) and will only be displayed in the other days, in that example, the shift will only be displayed in `2024-02-02`. The problem is the custom code in planning considers the shift in 2 days and so the start and end time are not displayed in the pill (=shift in that case) which is a bit annoying. This commit manages that special behavior to ensure the start and end time are displayed in that case since the shift is only displayed in 1 day. opw-3588166 closes odoo/odoo#120206 Forward-Port-Of: odoo/enterprise#57051 Forward-Port-Of: odoo/enterprise#56546
Before this commit, when the gantt view displays the current week, let's say from `2024-18-02` to `2024-24-02` and the planned dates of one pill is: - `start_datetime`: `2024-17-02 16:00:00` - `end_datetime`: `2024-18-02 00:00:00` (the end datetime of the pill should be the first column displayed in the gantt view), a traceback is occurred because the pill will not be displayed in the gantt view and so the grid column for that pill will be 0 and since the split tool uses the grid column for ea
Original PR description
Before this commit, when the gantt view displays the current week, let's say from `2024-18-02` to `2024-24-02` and the planned dates of one pill is: - `start_datetime`: `2024-17-02 16:00:00` - `end_datetime`: `2024-18-02 00:00:00` (the end datetime of the pill should be the first column displayed in the gantt view), a traceback is occurred because the pill will not be displayed in the gantt view and so the grid column for that pill will be 0 and since the split tool uses the grid column for each pill to place the different scissor to enable the split tool for the pills displayed on more than one column in the gantt view. This commit makes sure the split tool will skip the pill with column less than 1 to be sure `pill.grid.column[0] - 1` uses to create a array will not be less than 0. opw-3705995 closes #55807 Forward-Port-Of: odoo/enterprise#57483 Forward-Port-Of: odoo/enterprise#57482