Tuesday, May 28, 2024
46 changes
Resolved issues and error corrections
This fix ensures unread message counters in Discuss are initialized with the latest channel data, avoiding timing issues that could make counters appear incorrect during message notifications. It improves reliability for users without changing the messaging workflow.
Original PR description
The `channels.fetch()` was put inside `incrementUnreadCounter()` because it was assumed to be the only flow where the counter could change when all channels are not yet fetched, but it is also possible that the counter changes by just calling `getOrFetch()` in `_handleNotificationNewMessage()` and receiving a new counter directly from the RPC, therefore not doing the increment. In that case `initChannelsUnreadCounter` also becomes unreliable, so the force fetch is moved there instead. runbot-61556 runbot-62976
This fixes a subtle template handling issue where empty text could be saved differently after template inheritance changes. It helps avoid unnecessary differences in generated views and keeps existing templates stable when Studio customizations are applied.
Original PR description
When calling apply_inheritance_specs and moving a node (before after or inside), we merge the text content of the adjacents nodes. If the parent and target node both have no text, we should not set the text to an empty string. When a node has no text, it is serialized as follows: `<node/>` But if it has an empty string, it has the following representation: `<node></node>` In the linked PR, we now apply the studio inheritance manually, and since we use the resulting tree directly instead of parsing the result, the `remove_blank_text` option of the parser has no effect. This causes existing tests to show some difference. opw-3888345 opw-3924997
The Discuss notification settings menu now displays longer text correctly, including in languages such as Vietnamese. This prevents menu options from being cut off or misaligned when users mute channels, improving usability for multilingual teams.
Original PR description
Before this commit, the notification settings in discuss app that is used to mute channels was not showing items properly in some languages like vietnamese. This happens because the width is hard-coded to 150px as to keep the dropdown menu small. This commit fixes the issue by putting a max-width of 250px for dropdown menu and sub-menu, so that it keeps right positioning of submenu. If text is too long, it know wraps. 
Miscellaneous changes
**Current behavior:** In a multi-company environment, say we have a reusable box which has been used by multiple companies. While the box actively contains some product of companyA, companyB is not permitted to view their own stock transfers. **Expected behavior:** The current status of a package should not affect the accessibility of a company's picking history. **Steps to reproduce:** 1. Setup 2 companies, for both: Enable packages Enable stock warehouse locations
Original PR description
**Current behavior:** In a multi-company environment, say we have a reusable box which has been used by multiple companies. While the box actively contains some product of companyA, companyB is not…
**Current behavior:**
In a multi-company environment, say we have a reusable box which has been used by multiple companies. While the box actively contains some product of companyA, companyB is not permitted to view their own stock transfers.
**Expected behavior:**
The current status of a package should not affect the accessibility of a company's picking history.
**Steps to reproduce:**
1. Setup 2 companies, for both:
Enable packages
Enable stock warehouse locations
Enable multi-step routes -> set their in/out routes to 3-step (pick, pack, ship)
2. Create a reusable box type package, don't assign it to either company
3. In CompanyA, create a delivery using the reusable package and complete it so the package is fully emptied and ready to be reused
4. Switch to CompanyB, create a picking (any kind) using the same reusable box -don't finish the transfer- then switch back to CompanyA
5. Try to view Inventory transfers -> AccessError
**Cause of the issue:**
The delivery module adds the `_compute_shipping_weight()` method which is called on-demand when we try to open the transfers tree view. We will eventually look at packages from the picking that used the reusable package (which now 'belongs' to another company) and raise the AccessError.
**Fix:**
Use sudo() to read package records in the iteration over picking records.
We are only reading from pickings which belong to the current company, which makes the access check for the package records redundant (and as we see here problematic).
opw-3813917
Forward-Port-Of: odoo/odoo#166689
Forward-Port-Of: odoo/odoo#164677### Description of the issue/feature this PR addresses: We have demo data that is not a real case of use, and if we try to re-use the partner to invoice for the EDI module we will get an error. ### Current behavior before PR: We have a **Foreign Partner** from the United States have an identification type of Uruguay Resident (NIE). This is not a real case because if you are from outside of Uruguay you can not select the NIE document type or any document issued by the Uruguay government.
Original PR description
### Description of the issue/feature this PR addresses: We have demo data that is not a real case of use, and if we try to re-use the partner to invoice for the EDI module we will get an error. ###…
### Description of the issue/feature this PR addresses: We have demo data that is not a real case of use, and if we try to re-use the partner to invoice for the EDI module we will get an error. ### Current behavior before PR: We have a **Foreign Partner** from the United States have an identification type of Uruguay Resident (NIE). This is not a real case because if you are from outside of Uruguay you can not select the NIE document type or any document issued by the Uruguay government. Also if we want to re-use the demo partner to create new invoices and test the Send and Print functionality we are not able to send emails because the partners do not have an email set. ### Desired behavior after PR is merged: We fixed this in the demo so makes sense. Now we have two demo partners: * Fix Foreign partner to a proper document type * Add a new partner, Resident Alien, who is a foreign person living in Uruguay which is the proper case for the use of NIE document type. * We add an email to the UY demo partner, this way we can use this partners to test send and print functionality. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166543
Currently, if you select a product that has variants, the popup window to choose the variants shows both active and inactive variants. Steps to reproduce: ------------------- * Make a quotation with the product `Desk Organizer` and select `Plastic` as its variant -> Confirm * Go to **Products** * Select `Desk Organizer` * Go to `Attributes & Variants` * Remove the `Plastic` option > The variant is now inactive * Go to the **Point of Sale** App * Open a shop session * Select the `D
Original PR description
Currently, if you select a product that has variants, the popup window to choose the variants shows both active and inactive variants. Steps to reproduce: ------------------- * Make a quotation with…
Currently, if you select a product that has variants, the popup window to choose the variants shows both active and inactive variants. Steps to reproduce: ------------------- * Make a quotation with the product `Desk Organizer` and select `Plastic` as its variant -> Confirm * Go to **Products** * Select `Desk Organizer` * Go to `Attributes & Variants` * Remove the `Plastic` option > The variant is now inactive * Go to the **Point of Sale** App * Open a shop session * Select the `Desk Organizer` product > Observation: the `Plastic` variant is shown Why the fix: ------------ We compare the workflow with sales, when doing a new quotation with the `Desk Organizer` product, the inactive variant is not an option to select. We now load the information about attribute values being active or not when loading the data to the POS Session. All attributes that are inactive will not be shown in the product configurator. opw-3713374 Forward-Port-Of: odoo/odoo#166666 Forward-Port-Of: odoo/odoo#165110
Suppose a SO line of 1210 with: t1 fixed tax of 5, price include, affect base amount t2 21% price included tax Make a down payment of 200. The resulting created SO line is computed as (1210 + 5) * (200 / 1210) = 200.83 instead of 200.0. 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#16679
Original PR description
Suppose a SO line of 1210 with: t1 fixed tax of 5, price include, affect base amount t2 21% price included tax Make a down payment of 200. The resulting created SO line is computed as (1210 + 5) * (200 / 1210) = 200.83 instead of 200.0. 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#166792 Forward-Port-Of: odoo/odoo#166787
Before this PR, using the blur feature during a call on the public page will display an error popup. The library used to do so is not loaded. This PR fixes the issue. task-3948111 Forward-Port-Of: odoo/odoo#166743 Forward-Port-Of: odoo/odoo#166707
Original PR description
Before this PR, using the blur feature during a call on the public page will display an error popup. The library used to do so is not loaded. This PR fixes the issue. task-3948111 Forward-Port-Of: odoo/odoo#166743 Forward-Port-Of: odoo/odoo#166707
Forward-Port-Of: odoo/odoo#166350
Original PR description
Forward-Port-Of: odoo/odoo#166350
Forward-Port-Of: odoo/odoo#166818
Original PR description
Forward-Port-Of: odoo/odoo#166818
## Issue: - when you open a calendar event popover, you can't see its time and duration ## Steps To Reproduce: - In mobile view, go to calendar and create an event. - Click on the event and notice you can't see it's time and duration. ## Solution: - We want to display the time in the popover for all modes. Therefore, I removed the `scale === "month"` condition from `showTime`. The `showTime` variable is used to set the `isTimeHidden` attribute, which is then checked in the `computeDate
Original PR description
## Issue: - when you open a calendar event popover, you can't see its time and duration ## Steps To Reproduce: - In mobile view, go to calendar and create an event. - Click on the event and notice you can't see it's time and duration. ## Solution: - We want to display the time in the popover for all modes. Therefore, I removed the `scale === "month"` condition from `showTime`. The `showTime` variable is used to set the `isTimeHidden` attribute, which is then checked in the `computeDateTimeAndDuration` function of the calendar popover. opw-3829004 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166279 Forward-Port-Of: odoo/odoo#160907
When uploading a file, the activity ID is now sent to the server. This will help (for example) to avoid creating a second document if the file is uploaded in the context of an existing activity. ENT PR: https://github.com/odoo/enterprise/pull/59796 opw-3458850 Forward-Port-Of: odoo/odoo#166593 Forward-Port-Of: odoo/odoo#159943
Original PR description
When uploading a file, the activity ID is now sent to the server. This will help (for example) to avoid creating a second document if the file is uploaded in the context of an existing activity. ENT PR: https://github.com/odoo/enterprise/pull/59796 opw-3458850 Forward-Port-Of: odoo/odoo#166593 Forward-Port-Of: odoo/odoo#159943
The date_deadline propagation would update the sale records multiple times depending on some configuration (check example below). This happens because 'already_propagate_ids' is copied at the beginning of _set_date_deadline (set | set = new set). So, when a child move propagates to multiple other moves, it is not known by the parent move, which will redo the propagation. To prevent this, we always keep the same reference for 'already_propagate_ids' (context: 'date_deadline_propagate_ids'). Th
Original PR description
The date_deadline propagation would update the sale records multiple times depending on some configuration (check example below). This happens because 'already_propagate_ids' is copied at the…
The date_deadline propagation would update the sale records multiple times depending on some configuration (check example below). This happens because 'already_propagate_ids' is copied at the beginning of _set_date_deadline (set | set = new set). So, when a child move propagates to multiple other moves, it is not known by the parent move, which will redo the propagation.
To prevent this, we always keep the same reference for 'already_propagate_ids' (context: 'date_deadline_propagate_ids'). This means that a parent and child move share the exact same Set, and when the child move updates the Set, it also updates the parent Set. So when a child move propagates, the parent will know which moves have been done.
MOVES LINKAGE
```
Move B
/ | \
Move A | Move D
\ | /
Move C
```
PROPAGATION GRAPHS:
```
BEFORE | AFTER
------------+--------
A | A
/ \ | |
C B | B
/ \ / \ | |
B D C D | C
| | | | | |
D B D C | D
------------+--------
11 | 4 NUMBER OF CALLS
```
OPW-3904178
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#164734**Current behavior before PR:** Clicking the checkbox triggered the `mousedown` event, where the `preventDefault` function prevented the list from gaining focus. Consequently, without any focused element, clicking the breadcrumb (`o_back_button`) to navigate back failed to trigger the `blur` event, resulting in unsaved changes. **Desired behavior after PR is merged:** After removing `preventDefault` from the `mousedown` event, clicking the checkbox will now set focus on it. As a re
Original PR description
**Current behavior before PR:** Clicking the checkbox triggered the `mousedown` event, where the `preventDefault` function prevented the list from gaining focus. Consequently, without any focused element, clicking the breadcrumb (`o_back_button`) to navigate back failed to trigger the `blur` event, resulting in unsaved changes. **Desired behavior after PR is merged:** After removing `preventDefault` from the `mousedown` event, clicking the checkbox will now set focus on it. As a result, when the breadcrumb `o_back_button` is clicked, it will trigger the `blur` event, leading to the execution of `onWysiwygBlur` in `html_field`, which will commit(save) our changes. task-3346155 Forward-Port-Of: odoo/odoo#126007
Desired behavior after PR is merged: I. This PR implements a functionality where pressing the `Escape` key removes the transform widget from the image. II. Also it ensures that pressing any character key does not result in the removal of the image when the transform widget is active. task-3839151 Forward-Port-Of: odoo/odoo#160071
Original PR description
Desired behavior after PR is merged: I. This PR implements a functionality where pressing the `Escape` key removes the transform widget from the image. II. Also it ensures that pressing any character key does not result in the removal of the image when the transform widget is active. task-3839151 Forward-Port-Of: odoo/odoo#160071
### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a backorder - Create a new MO for 2 units of a product and produce 1 unit #### > A wizzard appears to ask you if you want to create a backorder ### Cause of the issue: Clicking on the produce button will call the "button_mark_done" method. However, the parameters of backorder creations are not checked before the wizzard generation: https
Original PR description
### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a backorder - Create a new MO for 2 units of a product and produce 1 unit #### > A wizzard appears to ask you if you want to create a backorder ### Cause of the issue: Clicking on the produce button will call the "button_mark_done" method. However, the parameters of backorder creations are not checked before the wizzard generation: https://github.com/odoo/odoo/blob/5c2f60ae2b8eb6699bd322bc4ea3d5054c7aea37/addons/mrp/models/mrp_production.py#L2118-L2120 will call the opw-3890886 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164560
This commit fixes an issue with the mailing_mailing_test wizard in mass_mailing. When sending a test email the snippet `s_mail_block_header_view` contains a placeholder link that is replaced by the actual link when rendered. When the user sends a test mailing, the mail sent will still contain the placeholder link without being replaced. This means that when clicking on it the user is redirected to a 404 error as this is a mere placeholder. This link isn't replaced because the mail created in
Original PR description
This commit fixes an issue with the mailing_mailing_test wizard in mass_mailing. When sending a test email the snippet `s_mail_block_header_view` contains a placeholder link that is replaced by the…
This commit fixes an issue with the mailing_mailing_test wizard in mass_mailing. When sending a test email the snippet `s_mail_block_header_view` contains a placeholder link that is replaced by the actual link when rendered. When the user sends a test mailing, the mail sent will still contain the placeholder link without being replaced. This means that when clicking on it the user is redirected to a 404 error as this is a mere placeholder. This link isn't replaced because the mail created inside testing wizard did not give a res_id, linked to a `mailing.contact`, to the `mail.mail` created. This led the function `_prepare_outgoing_list` to be exited prematurely without replacing any placeholder. This commit fixes the issue by adding a res_id linked to the current user to the mail.mail created in order for the method to finish its execution. But we don't want the unsubscribe links to be replaced, as the user could blacklist himself. Thus we added a context key `send_as_test` which blocks the replacement of the unsubscribe link. task-3869575 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165711
### Steps to reproduce: - Create a PO: - 1 x storable product 1 - 1 x storable product 2 - Confirm the PO - Change the quantity of the PO line of product 1 to 0 (this modifies the associated delivery accordingly) - Click on the customer to open the res.partner form - Click on the "On-Time Rate" smart button #### > Traceback: psycopg2.errors.DivisionByZero ### Cause of the issue: Clicking on that smart button will call the "_read_group" method and the following sql expressio
Original PR description
### Steps to reproduce: - Create a PO: - 1 x storable product 1 - 1 x storable product 2 - Confirm the PO - Change the quantity of the PO line of product 1 to 0 (this modifies the associated delivery…
### Steps to reproduce: - Create a PO: - 1 x storable product 1 - 1 x storable product 2 - Confirm the PO - Change the quantity of the PO line of product 1 to 0 (this modifies the associated delivery accordingly) - Click on the customer to open the res.partner form - Click on the "On-Time Rate" smart button #### > Traceback: psycopg2.errors.DivisionByZero ### Cause of the issue: Clicking on that smart button will call the "_read_group" method and the following sql expression will be added to the associated query: https://github.com/odoo/odoo/blob/b4620c123b753caf2b77472a8d6c42d767471c53/addons/purchase_stock/report/vendor_delay_report.py#L57-L60 The error is therefore rasied because the SUM(qty_total) associated to product 1 was reset to 0 because of our change on the PO line. ### Fix: Since SUM(qty_total) of 0 signifies that no units of that product was not expected to be delivered for that customer. As such they should be removed from the products whose "On-Time Rate" is computed from the vendor.delay.report's. opw-3852055 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166721 Forward-Port-Of: odoo/odoo#162632
Purpose ------- If you remove all groups of dashboard and save, the dashboard disappears and there's no way to find it back. Specification ------------- make the field required. Task: 3770194 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166805
Original PR description
Purpose ------- If you remove all groups of dashboard and save, the dashboard disappears and there's no way to find it back. Specification ------------- make the field required. Task: 3770194 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166805
Computation of sale.order.expected_date is done in sale module and overridden in sale_stock. Both function are doing mostly the same, except when it is selecting the min or max date from the sale order lines dates list based on the picking policy. Use a dedicated function to chose the final date out of the SOL dates, to simplify the override (and avoid calling the method `_expected_date` twice for each line. Also use `_expected_date` when preparing the procurement, to avoid duplicated cod
Original PR description
Computation of sale.order.expected_date is done in sale module and overridden in sale_stock. Both function are doing mostly the same, except when it is selecting the min or max date from the sale order lines dates list based on the picking policy. Use a dedicated function to chose the final date out of the SOL dates, to simplify the override (and avoid calling the method `_expected_date` twice for each line. Also use `_expected_date` when preparing the procurement, to avoid duplicated code (and ease overrides). Forward-Port-Of: odoo/odoo#165519
Prior to this commit, if a product wasn't loaded into the PoS, it would result undefined in the model. For instance, if one of the products in a combo product wasn't loaded into the PoS, an error would be raised when clicking on its combo product. This commit resolves the issue by ensuring that missing products are loaded, thereby preventing such errors. In addition, this commit introduces a domain to restrict the category, if applicable. opw-3810994 --- I confirm I have signed the CLA an
Original PR description
Prior to this commit, if a product wasn't loaded into the PoS, it would result undefined in the model. For instance, if one of the products in a combo product wasn't loaded into the PoS, an error would be raised when clicking on its combo product. This commit resolves the issue by ensuring that missing products are loaded, thereby preventing such errors. In addition, this commit introduces a domain to restrict the category, if applicable. opw-3810994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160340
Prior to this commit, enabling the multi-employee option without any employees in the database would result in no action upon selecting cashier. This could lead to confusion. With this commit, an error message is displayed in such scenarios, enhancing user feedback and preventing confusion. opw-3851823 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164596 Forward-Port-Of: odoo/odoo#160646
Original PR description
Prior to this commit, enabling the multi-employee option without any employees in the database would result in no action upon selecting cashier. This could lead to confusion. With this commit, an error message is displayed in such scenarios, enhancing user feedback and preventing confusion. opw-3851823 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164596 Forward-Port-Of: odoo/odoo#160646
Prior to this commit, if a partner was not loaded into the PoS, their name would not be displayed in the sale order list. This commit resolves this issue by ensuring missing partners are loaded when retrieving sale orders. opw-3881799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164603
Original PR description
Prior to this commit, if a partner was not loaded into the PoS, their name would not be displayed in the sale order list. This commit resolves this issue by ensuring missing partners are loaded when retrieving sale orders. opw-3881799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164603
Helper methods for building a partner/employee address in a SEPA payment report. opw-3716705 Forward-Port-Of: odoo/odoo#166205
Original PR description
Helper methods for building a partner/employee address in a SEPA payment report. opw-3716705 Forward-Port-Of: odoo/odoo#166205
[FIX] portal, website: allow to grant portal access for certain users Context: - Have a db with two websites (website1 and website2) with two different domains. - For those two websites, make sure that the "Shared Customer Accounts" setting is disabled. The user is so forced to create an account per website. - As a visitor, create an account in each website using the same email address. -> No issue; it is possible to create two accounts with the same email address. Steps to repr
Original PR description
[FIX] portal, website: allow to grant portal access for certain users Context: - Have a db with two websites (website1 and website2) with two different domains. - For those two websites, make sure…
[FIX] portal, website: allow to grant portal access for certain users Context: - Have a db with two websites (website1 and website2) with two different domains. - For those two websites, make sure that the "Shared Customer Accounts" setting is disabled. The user is so forced to create an account per website. - As a visitor, create an account in each website using the same email address. -> No issue; it is possible to create two accounts with the same email address. Steps to reproduce the issue: - Create two contacts (e.g. partner or customer) with the same email address. One is linked to website1, the other is linked to website2. - Select them, click on "Action" and then on "Grant portal access". - Click on "Grant Access" for the first contact; it works as expected. -> It is not possible to grant access for the second contact. The goal of this commit is to ensure that the two described behaviors lead to the same results. More specifically, it should be possible to grant portal access for two partners that have: - The same email address but are linked to different websites that have the "Shared Customer Accounts" setting disabled. - The same email address. One user is linked to a website that has the "Shared Customer Accounts" setting disabled and the other is not linked to a website. It should however not be possible to grant portal access for two partners that have: - The same email address and are linked to the same website that has the "Shared Customer Accounts" setting disabled. - The same email address and are not linked to a website. It should also not be possible to grant portal access for a partner that is not linked to a website if it exists a user with the same email address that is linked to the current website. Indeed, in this situation, the partner is redirected to the current website at the creation of its account and an "Access Denied" message would then be displayed. To solve the problem, the method `_get_similar_user_domain()` has been implemented in the "website" module. Its goal is to build the domain needed to find the users that have the same email than partners depending on their linked website characteristics. The `_is_portal_similar_than_user()` method has also been introduced. Its goal is to check if the credentials of a portal user and a user are the same. If it is the case, `email_state` field of the portal user is set to `exist`. task-3640503 Forward-Port-Of: odoo/odoo#166730 Forward-Port-Of: odoo/odoo#148482