Wednesday, February 14, 2024
87 changes · master
Enhancements to existing features
The web module's notification alert tests were moved to a newer testing framework. This improves maintainability and helps ensure notification behavior remains reliable without changing the user-facing product.
Original PR description
task-3705027
Emoji-only chat messages now appear in a larger font, making quick reactions more expressive and easier to see. The update also improves how frequently used emojis are tracked by relying on the emoji picker’s more accurate behavior.
Original PR description
This PR increases the size of the message body when the later only contains emojis. task-3651454
The web module's automated checks for boolean toggle fields were moved to the newer testing framework. This helps keep quality checks maintainable and reliable without changing how users interact with the product.
Original PR description
task-id: 3705027
The automation setup screen now hides an option that does not apply to time-based triggers. This reduces confusion for users configuring scheduled automations by showing only the relevant filtering field.
Original PR description
Time-based trigger do not use the field at all and instead do their filtering based solely on the filter_domain field (since there is no *pre* step, the automation is not triggered by a change). Displaying the field in those case is a bit unclear.
The web module's condition tree tests were converted to a newer testing framework. This helps keep quality checks easier to maintain and supports more reliable future development without changing user-facing behavior.
Original PR description
task-id: 3705027
This update adds a test to confirm that a mail-related internal process runs correctly when multiple records are handled. It helps improve reliability and reduces the chance of future regressions in messaging features.
Suggested recipients for messages are now added directly to the conversation data used by Odoo's messaging tools. This streamlines how recipient suggestions are prepared and should make the messaging experience more consistent across related views.
Original PR description
Change the format of return value from `_message_add_suggested_recipient` method to insert suggested recipients directly in the thread model. With this change (follow-up of PR https://github.com/odoo/odoo/pull/151555), all the fetched thread data in `ThreadService` are directly inserted into the thread model. [Related Enterprise PR](https://github.com/odoo/enterprise/pull/56046)
This update improves Odoo's internal web testing tools by making it easier to trace network activity and reuse common test setup helpers. It helps developers diagnose issues faster and maintain web interface tests more consistently, with no direct change for end users.
Original PR description
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 stores suggested message recipients directly in the conversation data used by its messaging features. This supports more consistent recipient handling across apps such as Helpdesk and Studio, with mainly internal test updates and low business disruption.
Original PR description
Adapt tests because of changing the format of return value from `_message_add_suggested_recipient` method to insert suggested recipients directly in the thread model. [Related Odoo PR](https://github.com/odoo/odoo/pull/153012)
Resolved issues and error corrections
Point of Sale preparation displays now show the full product name including variant details. This helps staff identify ordered items accurately when products have multiple variants, reducing preparation mistakes.
Original PR description
Current behavior: When you create a product with some variant (Never create option), and add them to be displayed on the pos_preparation_display they appear without the variant name. Steps to reproduce: - Create a product with some variant (Never create option), and add them to a pos category. - Setup a pos_preparation_display with the pos category you selected before. - Open a PoS linked to the pos_preparation_display. - Add a product with variant to the order. - Validate the order. - Check the display, the product name is shown without the variant name. opw-3671479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
The color picker field’s automated tests were moved to Odoo’s newer testing framework. This helps keep the web module easier to maintain and supports more reliable future development, with no expected change for end users.
Original PR description
This commit migrates the color_picker_field tests to the new test framework Hoot. task-3705027
Miscellaneous changes
Before this commit, opening a restaurant without any defined floors would result in a failure. This was due to the use of `activeFloor.background_color` to set the color, while activeFloor was not defined in cases where no floors were present. opw-3729416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153243
Original PR description
Before this commit, opening a restaurant without any defined floors would result in a failure. This was due to the use of `activeFloor.background_color` to set the color, while activeFloor was not defined in cases where no floors were present. opw-3729416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153243
This update prevents automated web tests from accidentally contacting real online services when a required mock is missing. It helps keep test results predictable and safer by failing fast when test setup is incomplete, while also ensuring these test files are properly checked by linting.
Original PR description
Previously, if the fetch function was not mocked in a test, it would fall back to the real fetch function and perform a network request. This is never desirable. This commit throws instead when attempting to make a request without having mocked the fetch function beforehand, and fixes one test that was making a real request for lack of having mocked fetch.
Purchase order emails now avoid showing the deadline next to the amount for confirmed orders, reducing confusion about whether that date is a payment due date. Requests for quotation still show the deadline when available, while confirmed purchase orders focus on the amount.
Original PR description
Steps to reproduce: send a confimed PO by email to the vendor Bug: the due date being right next to the amout confuses the client into thinking it's the date when payment is due Fix: -just display deadline for RFQs -just display Amount for confirmed PO opw-3664112
The preparation display now shows the full product name, including variant details, for Point of Sale orders. This helps staff identify the exact item to prepare and reduces confusion when products have similar names.
Original PR description
Current behavior: When you create a product with some variant (Never create option), and add them to be displayed on the pos_preparation_display they appear without the variant name. Steps to reproduce: - Create a product with some variant (Never create option), and add them to a pos category. - Setup a pos_preparation_display with the pos category you selected before. - Open a PoS linked to the pos_preparation_display. - Add a product with variant to the order. - Validate the order. - Check the display, the product name is shown without the variant name. opw-3671479
The GST return period form now correctly shows the tax unit field as soon as a company with tax unit settings is selected. This avoids confusion and extra save steps when creating new records.
Original PR description
Issue:
if a new record is created and tax_unit
is available, then field still remains invisible
unless user, saves the record
Solution:
`_compute_display_tax_unit` depending on `company_id` will resolve this issue
task-3727834## Description Domains of the form ```python [('stored_Many2X.id', '=/!=/in/not in', list_of_ids)] ``` will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table. There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly
Original PR description
## Description
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly referencing the `field` from the `model`. So in some cases using an explicit `.id` would be a wanted, if the intention was to apply the `ir.rule`.
## Fix
Remove the `.id` from left leafs of domains that if the field is stored, and the `comodel` doesn't have `ir.rule` associated with it, or the `ir.rule` application is redundant/not needed.
task-3735923
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#153450Have a grouped list view s.t. there's a group with enough records to have a pager in the group. Go to the second page of that group. Then, apply a filter such that there's only a single page remaining in the group. Before this commit, no record was displayed, because the previous offset wasn't reset to 0 it should have been. With this commit, the offset is recursively reset, so we correctly display the records of the first page after a reload. Description of the issue/feature this PR addresse
Original PR description
Have a grouped list view s.t. there's a group with enough records to have a pager in the group. Go to the second page of that group. Then, apply a filter such that there's only a single page remaining in the group. Before this commit, no record was displayed, because the previous offset wasn't reset to 0 it should have been. With this commit, the offset is recursively reset, so we correctly display the records of the first page after a reload. 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#153494
When a user is modified to grant access to new groups, user is auto-enrolled to all slide courses that have a auto-enroll policy for any of the new groups. However, that auto-enrolling process was not working correctly due to how values to be written to the user are coming. In order to know what are the actual new groups, values need to be pre-processed, which was not being done. This commit fixes the above issue by pre-processing written values before extracting new groups. --- I co
Original PR description
When a user is modified to grant access to new groups, user is auto-enrolled to all slide courses that have a auto-enroll policy for any of the new groups. However, that auto-enrolling process was not working correctly due to how values to be written to the user are coming. In order to know what are the actual new groups, values need to be pre-processed, which was not being done. This commit fixes the above issue by pre-processing written values before extracting new groups. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153138
Issue: When purchasing tickets for an event, if the quantity of tickets is reduced directly from the cart, payment can be processed for the reduced number of tickets while the excess registrations remain incorrectly open in the database. Steps to Reproduce: 1 Install Events Online Ticketing. 2 Create or select an event with open registrations. 3 Add 3 registrations to your cart and proceed to checkout. 4 In the payment process, go to 'Review Order' and reduce the quantity of tickets. 5 C
Original PR description
Issue: When purchasing tickets for an event, if the quantity of tickets is reduced directly from the cart, payment can be processed for the reduced number of tickets while the excess registrations…
Issue: When purchasing tickets for an event, if the quantity of tickets is reduced directly from the cart, payment can be processed for the reduced number of tickets while the excess registrations remain incorrectly open in the database. Steps to Reproduce: 1 Install Events Online Ticketing. 2 Create or select an event with open registrations. 3 Add 3 registrations to your cart and proceed to checkout. 4 In the payment process, go to 'Review Order' and reduce the quantity of tickets. 5 Complete the checkout and payment. 6 Upon inspecting the database for the same event, you'll notice an inconsistency: the number of attendees is higher than it should be. Solution: This issue arises from the implementation of `_compute_registration_status`, which only considers the sale order line and marks registrations as cancelled only if the entire order line is cancelled. This means either all 3 registrations are cancelled, or none. The solution introduced here addresses this by checking for registrations already marked as cancelled and incorporating them into the cancellation logic, ensuring accurate tracking of active and cancelled registrations. opw-3653452 Forward-Port-Of: odoo/odoo#150463
Before this commit: When the user creates new stages or groups in Kanban view and adds new tasks with particular states and then if the user clicks on any colour in the progressbar then the filter gets applied on all the groups or stages. Observerd Behaviour: The filter is applied on all the groups or stages.So, if we click on a colour in the progressbar suppose colour Green to filter out Approved task(s) of a particular stage then in that stage or group only the Approved task(s) would be v
Original PR description
Before this commit: When the user creates new stages or groups in Kanban view and adds new tasks with particular states and then if the user clicks on any colour in the progressbar then the filter…
Before this commit: When the user creates new stages or groups in Kanban view and adds new tasks with particular states and then if the user clicks on any colour in the progressbar then the filter gets applied on all the groups or stages. Observerd Behaviour: The filter is applied on all the groups or stages.So, if we click on a colour in the progressbar suppose colour Green to filter out Approved task(s) of a particular stage then in that stage or group only the Approved task(s) would be visible. Also the filter would get applied on all other stages or groups created at that time. In those stages all the task with that state would be visible and rest of them would get blurred. Steps to produce: - Install `Project` and add a new project in it. - In the newly created project add some new stages or groups, each consisting some new tasks. - Give some states to those tasks through project state selector (for eg: Approved, Changes Requested). - Click on any particular colour in the `Progressbar` of any particular group or stage. Expected Behaviour: When the user clicks on any colour in the progressbar then it should filter out only those tasks which are associated with that color/state and only in that particular group or stage. Reason: https://github.com/odoo/odoo/blob/579ee6d9792050955fa80346fd57ad294efcdd62/addons/web/static/src/views/kanban/progress_bar_hook.js#L114 group.serverValue results as Undefined. Because when the data is being prepared here: https://github.com/odoo/odoo/blob/493d5c39982de79e6fb256dd8084bf592a740f77/addons/web/static/src/model/relational_model/dynamic_group_list.js#L222-L231 there is no serverValue provided. So, whenever a group is getting created here serverValue `Undefined` as value. https://github.com/odoo/odoo/blob/493d5c39982de79e6fb256dd8084bf592a740f77/addons/web/static/src/model/relational_model/group.js#L25 Note: - There was a need to change the function name from `getServerValueFromGroupData` to `getGroupServerValue` as now now this function calculates serverValue while the data is being created and not when the data is already created. - The function is exported into another file as this function defines the basis to calculate serverValue and there is a necessity to calculate serverValue while data is being created. Task-3620697 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149694
Steps to reproduce: - insert a global filter with double quotes in its name (e.g. my "special" filter) - reference that filter with ODOO.FILTER.VALUE (remember you have to escape the " in the formula with a backslash \ =ODOO.FILTER.VALUE("my \"special\" filter") => the filter is not found Task: 3697855 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153542 Forward-Port-Of: odoo/odoo#150604
Original PR description
Steps to reproduce:
- insert a global filter with double quotes in its name (e.g. my "special" filter)
- reference that filter with ODOO.FILTER.VALUE (remember you have to escape the " in the formula with a backslash \ =ODOO.FILTER.VALUE("my \"special\" filter") => the filter is not found
Task: 3697855
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#153542
Forward-Port-Of: odoo/odoo#150604Before this commit, an Outlook event without an organizer would fail to sync with Odoo. This commit fixes this issue by allowing events without an organizer to be synced from Outlook to Odoo. opw-3701839 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153495
Original PR description
Before this commit, an Outlook event without an organizer would fail to sync with Odoo. This commit fixes this issue by allowing events without an organizer to be synced from Outlook to Odoo. opw-3701839 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153495
In b69917e[1] the cron implementation was changed to unlink old visitors in batches of 1000 records. This was meant to deal with memory/timeout errors when dealing with large amounts of records. However it still searches for records with no limit, which in high record count scenarios and based on instance resources may still generate memory/timeout errors. Technically it could be considered "fine" for the cron to timeout since every batch is committed, so previously unlinked records a
Original PR description
In b69917e[1] the cron implementation was changed to unlink old visitors in batches of 1000 records. This was meant to deal with memory/timeout errors when dealing with large amounts of records.…
In b69917e[1] the cron implementation was changed to unlink old visitors in batches of 1000 records. This was meant to deal with memory/timeout errors when dealing with large amounts of records. However it still searches for records with no limit, which in high record count scenarios and based on instance resources may still generate memory/timeout errors. Technically it could be considered "fine" for the cron to timeout since every batch is committed, so previously unlinked records are not rolled back and the cron should eventually delete them all. However there are some edge cases where memory/time out errors would not be fine, like the cron failing during the first batch, which means no unlink operations would be committed to the database. Errors that are "fine" also generate noise and leave administrators wondering which errors they should ignore and which they should not. It also alarms non-technical customers since after all, they are seeing a reported error. Therefore the search limit and batch size have been added as arguments to the cron. This is completely opt-in since they have the previous values as their defaults. This makes it easy to customize and tune the performance of the job accordingly if required. [1] https://github.com/odoo/odoo/commit/b69917ec0e508f8354d831525c5c48ee79b5967a --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150476
The goal of this commit is to impove the comment in the `loadImageInfo` method. Forward-Port-Of: odoo/odoo#153554 Forward-Port-Of: odoo/odoo#153438
Original PR description
The goal of this commit is to impove the comment in the `loadImageInfo` method. Forward-Port-Of: odoo/odoo#153554 Forward-Port-Of: odoo/odoo#153438
The commit odoo/odoo@a72007508a985d95 fixed the dialog for the import of a module, but broke the (shared) view for the dialog of the installation of an industry. This commit fixes both dialog views. Before the commit:  After the commit:  And the import dialog remains as it was:  view for the dialog of the installation of an industry. This commit fixes both dialog views. Before the commit:  After the commit:  And the import dialog remains as it was:  Forward-Port-Of: odoo/odoo#153013
Issue: - When checking future accruals in the Time Off dashboard, the Balance view doesn't update correctly. For example, with an accrual plan of 1h per month starting on 30/11/23, the balance in December should show 2h but incorrectly shows only 1.12h. - This happens because the '_get_future_leaves_on' method always returns values in days, ignoring the 'type_request_unit' of the allocation. Steps to Reproduce: - In the time-off app set an accrual plan: 1h per month, accrued on the fir
Original PR description
Issue: - When checking future accruals in the Time Off dashboard, the Balance view doesn't update correctly. For example, with an accrual plan of 1h per month starting on 30/11/23, the balance in December should show 2h but incorrectly shows only 1.12h. - This happens because the '_get_future_leaves_on' method always returns values in days, ignoring the 'type_request_unit' of the allocation. Steps to Reproduce: - In the time-off app set an accrual plan: 1h per month, accrued on the first day of the month. - add a new allocation to Mitchell Admin with that plan - Notice that In the dashboard the balance is 1h - Change the date to next month, new amount is 1.12h, in stead of 2 Solution: - Added a check to correctly calculate future accruals in hours when type_request_unit is 'hour', ensuring accurate hour-based balances. opw-3685077 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152870
## Description Domains of the form ```python [('stored_Many2X.id', '=/!=/in/not in', list_of_ids)] ``` will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table. There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly
Original PR description
## Description
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly referencing the `field` from the `model`. So in some cases using an explicit `.id` would be a wanted, if the intention was to apply the `ir.rule`.
## Fix
Remove the `.id` from left leafs of domains that if the field is stored, and the `comodel` doesn't have `ir.rule` associated with it, or the `ir.rule` application is redundant/not needed. `.id`
task-3735923
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#153475Forward-Port-Of: odoo/odoo#153654
Original PR description
Forward-Port-Of: odoo/odoo#153654
When reading values in reactive objects, Owl's reactivity system will return reactive versions of the sub-objects to allow tracking reads in depth, so that changes to values in deep object hierarchies can still cause components to render themselves if needed. Luxon objects are immutable. Since they cannot change and values inside them cannot change either, tracking reads within luxon objects is pure overhead. This commit makes luxon objects non reactifiable by setting the Symbol.toStringTa
Original PR description
When reading values in reactive objects, Owl's reactivity system will return reactive versions of the sub-objects to allow tracking reads in depth, so that changes to values in deep object hierarchies can still cause components to render themselves if needed. Luxon objects are immutable. Since they cannot change and values inside them cannot change either, tracking reads within luxon objects is pure overhead. This commit makes luxon objects non reactifiable by setting the Symbol.toStringTag property on the luxon classes, which is what Owl uses internally to determine if objects can be made reactive. It will also cause some of these objects to serialize to more specific strings instead of just [object Object], eg [object LuxonZone]. Forward-Port-Of: odoo/odoo#153540 Forward-Port-Of: odoo/odoo#153387
Issue: When the notification webhook is enabled for Adyen, sometimes the response back causes an SQL concurrent update. Odoo then creates a retry towards Adyen, charging the customer card several times. Both the notification webhook and the payment controller are hit, and try updatingthe same row simultaneously, which causes this behavior. Steps to reproduce: This bug is not reproducible due to a connection issue for the Adyen test account. However, if the payment request would implement id
Original PR description
Issue: When the notification webhook is enabled for Adyen, sometimes the response back causes an SQL concurrent update. Odoo then creates a retry towards Adyen, charging the customer card several…
Issue: When the notification webhook is enabled for Adyen, sometimes the response back causes an SQL concurrent update. Odoo then creates a retry towards Adyen, charging the customer card several times. Both the notification webhook and the payment controller are hit, and try updatingthe same row simultaneously, which causes this behavior. Steps to reproduce: This bug is not reproducible due to a connection issue for the Adyen test account. However, if the payment request would implement idempotency we could prevent billing the customer on the same request if the request reaches this collision and is retried multiple times. Description A first payment request is sent to Adyen. The card is charged and Adyen answers that all went as expected. We try to process the payment, but a concurrent access error occurs. A retry is done. A payment request is sent again to Adyen, The card is charged AGAIN and Adyen answers that all went as expected. We try to process the payment, but a concurrent access error occurs. For each retry, the request is sent and the card is charged. If the first retry succeeds, then Odoo can finish the process. There will be only 1 payment transaction on Odoo's side (others have been rollbacked) but there will be 3 on Adyen's side and the card will be charged 3 times. This PR fixes this behaviour by adding the idempotency key to the headers with the hash of the transaction reference and the database UUID, we prevent duplicate payments to happen. OPW-3584300 Forward-Port-Of: odoo/odoo#153734 Forward-Port-Of: odoo/odoo#150102
Product template "property_account_expense_id" and "property_account_creditor_price_difference" fields must stay editable in cases even if not "can be puchased". Since it being readonly is trivial, better leave it writeable instead of implementing cross module readonly logic. Task: 3695677 Forward-Port-Of: odoo/odoo#150601
Original PR description
Product template "property_account_expense_id" and "property_account_creditor_price_difference" fields must stay editable in cases even if not "can be puchased". Since it being readonly is trivial, better leave it writeable instead of implementing cross module readonly logic. Task: 3695677 Forward-Port-Of: odoo/odoo#150601
In tax report, ve38 line should display the tax excluded amount, not the tax amount. Task link: https://www.odoo.com/web#model=project.task&id=3609402 opw-3609402 Forward-Port-Of: odoo/odoo#153558 Forward-Port-Of: odoo/odoo#145570
Original PR description
In tax report, ve38 line should display the tax excluded amount, not the tax amount. Task link: https://www.odoo.com/web#model=project.task&id=3609402 opw-3609402 Forward-Port-Of: odoo/odoo#153558 Forward-Port-Of: odoo/odoo#145570
This PR fixes an unconsistent forestack icon within the `sale_stock` module. Prior to this PR, the forecast icon was using a `text-primary` class, making it unconsistent regarding the other forecast icons. We also add a missing `cursor-pointer` class to fix the improve the hover state and the visual feedback of the link. task-3582145 Forward-Port-Of: odoo/odoo#153618 Forward-Port-Of: odoo/odoo#140959
Original PR description
This PR fixes an unconsistent forestack icon within the `sale_stock` module. Prior to this PR, the forecast icon was using a `text-primary` class, making it unconsistent regarding the other forecast icons. We also add a missing `cursor-pointer` class to fix the improve the hover state and the visual feedback of the link. task-3582145 Forward-Port-Of: odoo/odoo#153618 Forward-Port-Of: odoo/odoo#140959
### Steps to reproduce - Create a child company. - In the child company, create a new sales journal. - Create and confirm an invoice using this new journal. - Attempt to create a credit note from that invoice. In this scenario, you would encounter an error. ### Cause The `AccountMoveReversal` wizard is currently setting its company to the root company of the moves, which in this case is the parent company. However, its journal is set to the one created in the child company. This m
Original PR description
### Steps to reproduce - Create a child company. - In the child company, create a new sales journal. - Create and confirm an invoice using this new journal. - Attempt to create a credit note from…
### Steps to reproduce - Create a child company. - In the child company, create a new sales journal. - Create and confirm an invoice using this new journal. - Attempt to create a credit note from that invoice. In this scenario, you would encounter an error. ### Cause The `AccountMoveReversal` wizard is currently setting its company to the root company of the moves, which in this case is the parent company. However, its journal is set to the one created in the child company. This mismatch causes an error due to company inconsistency. ### Fix The `company_id` of `AccountMoveReversal` will now be assigned to the company of the moves, rather than the root company. To ensure this works correctly, we also added a check to guarantee that all moves being reversed are from the same company. ### Note This fix also resolves an issue where a traceback occurred if two invoices were created (one in the child company and another in the parent company) and an attempt was made to reverse both simultaneously. opw-3640719 Forward-Port-Of: odoo/odoo#153412 Forward-Port-Of: odoo/odoo#147891
Steps to reproduce: -make an order -make a payment for it but do not validate it -close de session -remove the payment method used -open the pos again -traceback is shown Since the payment method is removed, when the session recovers the cached orders an error is raised since the payment method doesn't exist anymore. A try catch is added around the recovery of the cached orders. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior aft
Original PR description
Steps to reproduce: -make an order -make a payment for it but do not validate it -close de session -remove the payment method used -open the pos again -traceback is shown Since the payment method is removed, when the session recovers the cached orders an error is raised since the payment method doesn't exist anymore. A try catch is added around the recovery of the cached orders. 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#153706
Pivot/list monetary fields needs the company currency to display the value in the said currency format. Until now, a RPC was made to fetch the currency. However, since odoo/o-spreadsheet@8710839 and odoo/enterprise@8c0a785 the currency format is already in the model config. There's no need for the RPC. This saves one network request and one full spreadsheet evaluation (which would have occured after the request is done) Note: This optimization currently doesn't work for dashboards.
Original PR description
Pivot/list monetary fields needs the company currency to display the value in the said currency format. Until now, a RPC was made to fetch the currency. However, since odoo/o-spreadsheet@8710839 and odoo/enterprise@8c0a785 the currency format is already in the model config. There's no need for the RPC. This saves one network request and one full spreadsheet evaluation (which would have occured after the request is done) Note: This optimization currently doesn't work for dashboards. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153749 Forward-Port-Of: odoo/odoo#151725
This PR fixes 2 issues with discuss navigation: 1. Broken backwards navigation when going back and forth from the live chat session history. 2. Broken backwards navigation when trying to access the same thread than the current one. Steps to reproduce 1: - Open the command palette - Go to the live chat session history view - Click on one of your channels - History back => leads to the session history view - History forward => leads to discuss - History back => stays on discuss, his
Original PR description
This PR fixes 2 issues with discuss navigation: 1. Broken backwards navigation when going back and forth from the live chat session history. 2. Broken backwards navigation when trying to access the…
This PR fixes 2 issues with discuss navigation: 1. Broken backwards navigation when going back and forth from the live chat session history. 2. Broken backwards navigation when trying to access the same thread than the current one. Steps to reproduce 1: - Open the command palette - Go to the live chat session history view - Click on one of your channels - History back => leads to the session history view - History forward => leads to discuss - History back => stays on discuss, history is broken This occurs because the active id is not passed in the action context when navigating backwards which leads to the URL being pushed again in history (URL without active id is different). The active id should be put in the context when available. Steps to reproduce 2: - Go to discuss - Click on the active thread - History back => stuck on discuss, cannot navigate backwards anymore. We should not push in history when accessing the same thread than the current one. task-3422516 Forward-Port-Of: odoo/odoo#153754 Forward-Port-Of: odoo/odoo#152423
This commit's purpose is to fix the re apparition of personnal stage on the todo app when personnal stages are deleted one after the other. Step to reproduce: -login as Marc demo -open todo -delete any personnal stage without any todo in it -delete any personnal stage with at least one todo in it The personnal stage deleted first is now present again in the kanban view. Note that it is only a frontend bug. The record has been correctly removed from the db, and any action with it will tr
Original PR description
This commit's purpose is to fix the re apparition of personnal stage on the todo app when personnal stages are deleted one after the other. Step to reproduce: -login as Marc demo -open todo -delete…
This commit's purpose is to fix the re apparition of personnal stage on the todo app when personnal stages are deleted one after the other. Step to reproduce: -login as Marc demo -open todo -delete any personnal stage without any todo in it -delete any personnal stage with at least one todo in it The personnal stage deleted first is now present again in the kanban view. Note that it is only a frontend bug. The record has been correctly removed from the db, and any action with it will trigger a cache miss exception and reloading the view completly will removed those ghost stages definitly. Source of the problem: The problem is that the deletion is only reloading the view completly when a record with child data is removed. More precisly, the _deleteGroup function of the dynamic list triggers an rpc call to update the config of the component only when a record with child data is deleted, and that data need to be switched to another record, while when it is an empty record, the record is simply removed from the group field of the list. The issue is that there is thus a mismatch between the group in the list.config.groups and the list.group. And when the config is updated, only the list.config.groups is used to update the config, meaning it potentially still contains element that were already deleted. Solution: Doing a check up on the list.group to ensure that any deleted element is also removed from the config when an update is triggered. Note: I dont why Mitchel admin did not trigger the bug. Code wise, it should happends no matter the access right of the connectedd user. Version affected: master task - 3553101 https://www.odoo.com/web#id=3553101&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form 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#142536
Specification: This commit targets the scenario when an image is in the selection and the toolbar displays an AI option, which makes no sense as the generated response will replace the image. Desired behavior after PR is merged: The toolbar has been updated to show the AI option only for text-based scenario task-3733320 Forward-Port-Of: odoo/odoo#153190
Original PR description
Specification: This commit targets the scenario when an image is in the selection and the toolbar displays an AI option, which makes no sense as the generated response will replace the image. Desired behavior after PR is merged: The toolbar has been updated to show the AI option only for text-based scenario task-3733320 Forward-Port-Of: odoo/odoo#153190
Before this commit, the project task list view computed the list of selected records once for each cell, when rendering the list. As a consequence, this slowed down a lot the rendering on large tables (~1s for 80 records). With this commit, we compute the selection only once to render the whole table. 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 guidel
Original PR description
Before this commit, the project task list view computed the list of selected records once for each cell, when rendering the list. As a consequence, this slowed down a lot the rendering on large tables (~1s for 80 records). With this commit, we compute the selection only once to render the whole table. 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#153611
Rules always have a pricelist, so we can avoid an useless database query when we are computing the prices without any pricelist. Also makes sure that the modified context used for the pricelist items search is not propagated by enforcing the same context in the returned rules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153624
Original PR description
Rules always have a pricelist, so we can avoid an useless database query when we are computing the prices without any pricelist. Also makes sure that the modified context used for the pricelist items search is not propagated by enforcing the same context in the returned rules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153624
Add method '_get_discount_product' to allow to override the product used by the sale_order_discount wizard. Forward-Port-Of: odoo/odoo#153652
Original PR description
Add method '_get_discount_product' to allow to override the product used by the sale_order_discount wizard. Forward-Port-Of: odoo/odoo#153652
In this PR: ============================================= Before if all the lines were of service the error was displayed in a banner after error in response was received, but now before sending request the lines are checked if at least one line is of product and error is raised. task-3707483 Forward-Port-Of: odoo/odoo#153522 Forward-Port-Of: odoo/odoo#153215
Original PR description
In this PR: ============================================= Before if all the lines were of service the error was displayed in a banner after error in response was received, but now before sending request the lines are checked if at least one line is of product and error is raised. task-3707483 Forward-Port-Of: odoo/odoo#153522 Forward-Port-Of: odoo/odoo#153215
Bug === When we show the sample data of documents, it will choose a random value for the selection field. But document use a special option to make the browser generate the thumbnail of PDFs and then save it on the record. So, without this rule, it will try to update the record if "client_generated" has been chosen. Task-3697924 Forward-Port-Of: odoo/odoo#152490
Original PR description
Bug === When we show the sample data of documents, it will choose a random value for the selection field. But document use a special option to make the browser generate the thumbnail of PDFs and then save it on the record. So, without this rule, it will try to update the record if "client_generated" has been chosen. Task-3697924 Forward-Port-Of: odoo/odoo#152490
In previous versions the max size of a domain was bounded by psycopg memory limits. With the new SQL formatting mechanism the limit is bound by the maximum recursion limit in Python side. The purpose of this patch is to restore previous behavior. In 16.0: ``` >>> def make_dom(N): ... return [*('|' for x in range(N-1)), *(('login', '=', 'admin') for x in range(N))] ... >>> u.search(make_dom(9984)) res.users(2,) >>> u.search(make_dom(9985)) Traceback (most recent call last): File
Original PR description
In previous versions the max size of a domain was bounded by psycopg memory limits. With the new SQL formatting mechanism the limit is bound by the maximum recursion limit in Python side. The purpose…
In previous versions the max size of a domain was bounded by psycopg memory limits. With the new SQL formatting mechanism the limit is bound by the maximum recursion limit in Python side. The purpose of this patch is to restore previous behavior.
In 16.0:
```
>>> def make_dom(N):
... return [*('|' for x in range(N-1)), *(('login', '=', 'admin') for x in range(N))]
...
>>> u.search(make_dom(9984))
res.users(2,)
>>> u.search(make_dom(9985))
Traceback (most recent call last):
File "<input>", line 1, in <module>
u.search(make_dom(9985))
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 1520, in search
return res if count else self.browse(res)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5140, in browse
if not ids:
File "/home/odoo/src/odoo/16.0/odoo/tools/query.py", line 217, in __bool__
return bool(self._result)
File "/home/odoo/src/odoo/16.0/odoo/tools/func.py", line 28, in __get__
value = self.fget(obj)
File "/home/odoo/src/odoo/16.0/odoo/tools/query.py", line 210, in _result
self._cr.execute(query_str, params)
File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 321, in execute
res = self._obj.execute(query, params)
psycopg2.errors.SyntaxError: memory exhausted at or near ""login""
LINE 1: ...((("res_users"."login" = 'admin') OR ("res_users"."login" = ...
```
in 17.0 without this patch
```
>>> u.search(make_dom(1480))
res.users(2,)
>>> u.search(make_dom(1481))
<shortened output ...>
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
child = stack[-1].send(child)
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 86, in <genexpr>
if isinstance(child, SQL):
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
child = stack[-1].send(child)
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 86, in <genexpr>
if isinstance(child, SQL):
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
child = stack[-1].send(child)
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 86, in <genexpr>
if isinstance(child, SQL):
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
child = stack[-1].send(child)
RecursionError: maximum recursion depth exceeded
```
This issue was observed in upgrades in multiple instances. Example: MRP produces an OR domain with 2K terms for warehouse sub-locations that fail.
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#153755
Forward-Port-Of: odoo/odoo#153394Since fd2fb212c50952ca5a8e162ba5d82ce433cd5989, the sepa provider (enterprise module) behaves as a custom provider but despite some adaptations, the removal of providers on module uninstall was not properly adapted. The uninstall of the sepa provider failed as its inline template was not unlinked from the provider before the template deletion. This commit makes sure that custom providers are correctly considered in the uninstall util supposed to restore a provider to its state before th
Original PR description
Since fd2fb212c50952ca5a8e162ba5d82ce433cd5989, the sepa provider (enterprise module) behaves as a custom provider but despite some adaptations, the removal of providers on module uninstall was not properly adapted. The uninstall of the sepa provider failed as its inline template was not unlinked from the provider before the template deletion. This commit makes sure that custom providers are correctly considered in the uninstall util supposed to restore a provider to its state before the installation of its module. opw-3734697 opw-3721846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153690
## Description Domains of the form ```python [('stored_Many2X.id', '=/!=/in/not in', list_of_ids)] ``` will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table. There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly
Original PR description
## Description
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly referencing the `field` from the `model`. So in some cases using an explicit `.id` would be a wanted, if the intention was to apply the `ir.rule`.
## Fix
Remove the `.id` from left leafs of domains that if the field is stored, and the `comodel` doesn't have `ir.rule` associated with it, or the `ir.rule` application is redundant/not needed.
task-3735923
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#153460…arshal None unless allow_none is enabled Description of the issue/feature this PR addresses: When uses External API to fetch an invoice, if this invoice it's paid and the 'partner' hasn't 'company' return None instead False Current behavior before PR: TypeError: cannot marshal None unless allow_none is enabled Desired behavior after PR is merged: Should return an object with invoice_payments_widget as attribute. --- I confirm I have signed the CLA and read the PR guideline
Original PR description
…arshal None unless allow_none is enabled Description of the issue/feature this PR addresses: When uses External API to fetch an invoice, if this invoice it's paid and the 'partner' hasn't 'company' return None instead False Current behavior before PR: TypeError: cannot marshal None unless allow_none is enabled Desired behavior after PR is merged: Should return an object with invoice_payments_widget as attribute. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153362
Versions -------- - 17.0 - 17.1 - master Steps ----- 1. Go to Settings / Manage Languages; 2. select your current language; 3. set First Day of Week to something other than Sunday; 4. go to Time Off app. Issue ----- Weeks in year overview still start on a Sunday. Cause ----- Commit 52dae7a2f00c41222cf4518617d050efa8d34359 hardcoded `firstDay` to Sunday for the `hr_holidays` module. This was a workaround to some issues with `fullcalendar`'s week number calculations. Solut
Original PR description
Versions -------- - 17.0 - 17.1 - master Steps ----- 1. Go to Settings / Manage Languages; 2. select your current language; 3. set First Day of Week to something other than Sunday; 4. go to Time Off…
Versions -------- - 17.0 - 17.1 - master Steps ----- 1. Go to Settings / Manage Languages; 2. select your current language; 3. set First Day of Week to something other than Sunday; 4. go to Time Off app. Issue ----- Weeks in year overview still start on a Sunday. Cause ----- Commit 52dae7a2f00c41222cf4518617d050efa8d34359 hardcoded `firstDay` to Sunday for the `hr_holidays` module. This was a workaround to some issues with `fullcalendar`'s week number calculations. Solution -------- Remove the hardcoded `firstDay`, and add a custom week numbering function to be used on week, month, and year calendar views for consistent numbering that allows for different first days of the week. The function returns the ISO week number of the Monday nearest to the configured first day of the week, i.e. the following Monday when first day is set to Friday, Saturday or Sunday, the previous Monday if first day is set to Tuesday, Wednesday or Thursday. There were 3 main considerations for deciding a week numbering method: 1. no exisiting setting for users to decide on a method; 2. the ability to pick a first day of the week independent of locale; 3. the version of `luxon` used being unable to factor in locale. Addendum -------- This commit doesn't fix the issue with group-by week numbering in list view. These stem from `babel`'s inconsistent locale defaults and inability to take user-configured first day of the week into account. opw-3668175 Forward-Port-Of: odoo/odoo#148623
[FIX] website: correctly update carousel thumbnails on image insertion Steps to reproduce the bug: - Add an "Image Gallery" on the website. - Add a new image on the snippet. -> Problem: the thumbnail of the first image of the carousel has been replaced by the new added image. To solve the problem, the triggering of the `image_changed` event has been removed on extra image added. It was introduced by [1] to trigger the re-rendering of the thumbnail when adding a new image on the ca
Original PR description
[FIX] website: correctly update carousel thumbnails on image insertion Steps to reproduce the bug: - Add an "Image Gallery" on the website. - Add a new image on the snippet. -> Problem: the thumbnail…
[FIX] website: correctly update carousel thumbnails on image insertion Steps to reproduce the bug: - Add an "Image Gallery" on the website. - Add a new image on the snippet. -> Problem: the thumbnail of the first image of the carousel has been replaced by the new added image. To solve the problem, the triggering of the `image_changed` event has been removed on extra image added. It was introduced by [1] to trigger the re-rendering of the thumbnail when adding a new image on the carousel but was actually useless. Indeed, the mechanism was the same as now; when a new image was added on the carousel, the `website.gallery.slideshow` that already handles the thumbnails was re-rendered. An important think to note is that the system was also never intercepting this `image_changed` event as it was triggered on an element that was not in the DOM (as it was removed at the `_replaceContent()` call in the `slideshow()` method). However, since [2], the images rendered by the `website.gallery.slideshow` are replaced by the images (or the wrapped anchored images) returned by `_getImgHolderEls`. Therefore, `$newImageToSelect` is part of the DOM and the `image_changed` event is intercepted by the gallery option. As the active carousel item is always the first one of the carousel after a `website.gallery.slideshow` re-rendering, the system changed the thumbnail of the first item with the new added image. [1]: https://github.com/odoo/odoo/commit/85990768592cbdefbb178b5ffa38c1e29b9eeb87 [2]: https://github.com/odoo/odoo/commit/0fd2477d993e822fe6fd4497aace9f746af7a481 task-3736301 Forward-Port-Of: odoo/odoo#153717 Forward-Port-Of: odoo/odoo#153409
Description of the issue/feature this PR addresses: Prerequisite: - User A (admin) - User B (random internal) Steps: - Login as B - Find a chatter and send a log note or a message - Logout - Login with A - Delete user B and the contact related - Open the same chatter than above Current behavior before PR: - Multiple traceback due to "no author" - No avatar Desired behavior after PR is merged: - No traceback - Message avatar is the default one / the placeholder - Message au
Original PR description
Description of the issue/feature this PR addresses: Prerequisite: - User A (admin) - User B (random internal) Steps: - Login as B - Find a chatter and send a log note or a message - Logout - Login with A - Delete user B and the contact related - Open the same chatter than above Current behavior before PR: - Multiple traceback due to "no author" - No avatar Desired behavior after PR is merged: - No traceback - Message avatar is the default one / the placeholder - Message author name is the email_from field opw-3743727 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153793
Steps to reproduce: -Create a SO and sell a prepaid service in days -Set the timesheeting to days/half-days -Add a timesheet line on the task of the SO -Go to database/my/timesheets and look for the timesheets of the SO -> The days ordered are wrong Before PR: If you confirm the SO with the timesheeted SOL's uom as days and your timesheeting is made in days, the view will convert the amount of days as if it were hours, showing wrong values After PR: Made the report more robust
Original PR description
Steps to reproduce: -Create a SO and sell a prepaid service in days -Set the timesheeting to days/half-days -Add a timesheet line on the task of the SO -Go to database/my/timesheets and look for the timesheets of the SO -> The days ordered are wrong Before PR: If you confirm the SO with the timesheeted SOL's uom as days and your timesheeting is made in days, the view will convert the amount of days as if it were hours, showing wrong values After PR: Made the report more robust, now converting whatever unit the SOL has to either hours or days depending on the timesheet setting opw-3643988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153747 Forward-Port-Of: odoo/odoo#147944
The `author_id` of a `mail.mail` should always be a `res.partner` (cfr. [this line][1]). __Current behavior before commit:__ When `organizer.email` and `company.email` are empty, `author` is set to the user OdooBot instead of its corresponding partner. opw-3715380 [1]: https://github.com/odoo/odoo/blob/dcae15dcc072d14164d6454c35ce7d8d870e96ee/addons/mail/wizard/mail_compose_message.py#L107 Forward-Port-Of: odoo/odoo#153689
Original PR description
The `author_id` of a `mail.mail` should always be a `res.partner` (cfr. [this line][1]). __Current behavior before commit:__ When `organizer.email` and `company.email` are empty, `author` is set to the user OdooBot instead of its corresponding partner. opw-3715380 [1]: https://github.com/odoo/odoo/blob/dcae15dcc072d14164d6454c35ce7d8d870e96ee/addons/mail/wizard/mail_compose_message.py#L107 Forward-Port-Of: odoo/odoo#153689
Steps to reproduce: - Go to Website > Add menu items in a way that activates “auto-hide” (to set the overflowing menu items in a “+” dropdown) if the viewport was resized. - Go to “edit” mode (adding the sidebar reduces the current window width) > The “auto-hide” menu adaptation is disabled, and overflowing menu items are still visible. The goal of this commit is to fix the behavior described above (and potentially, issues that can result from the editor's "unbreakable" rollbacks on top m
Original PR description
Steps to reproduce: - Go to Website > Add menu items in a way that activates “auto-hide” (to set the overflowing menu items in a “+” dropdown) if the viewport was resized. - Go to “edit” mode (adding the sidebar reduces the current window width) > The “auto-hide” menu adaptation is disabled, and overflowing menu items are still visible. The goal of this commit is to fix the behavior described above (and potentially, issues that can result from the editor's "unbreakable" rollbacks on top menu) by preventing the unbreakable mechanism from detecting header changes and cancelling the auto-hide updates. Related to opw-3484742 X-original-commit: 02fb2d496f8820a909dfdc595e3389bb1467f194 Forward-Port-Of: odoo/odoo#153566 Forward-Port-Of: odoo/odoo#153563
Issue: ------ Since this commit[^1], a user who is not in the `Administration/Access Rights` group cannot modify certain fields available to him on his user profile (`livechat_username` and `livechat_lang_ids`). Solution: --------- As it is possible for a user to write to these fields, it is necessary to put them in `SELF_READABLE_FIELDS` in order to obtain sudo rights when writing if the environment user corresponds to the user to whom we want to write the new values. opw-3717266 [
Original PR description
Issue: ------ Since this commit[^1], a user who is not in the `Administration/Access Rights` group cannot modify certain fields available to him on his user profile (`livechat_username` and `livechat_lang_ids`). Solution: --------- As it is possible for a user to write to these fields, it is necessary to put them in `SELF_READABLE_FIELDS` in order to obtain sudo rights when writing if the environment user corresponds to the user to whom we want to write the new values. opw-3717266 [^1]: 78f6b83b348326ac0848692ca228a4650057f95c Forward-Port-Of: odoo/odoo#153750 Forward-Port-Of: odoo/odoo#152425
Description of the issue/feature this PR addresses: Current behavior before PR: The original fix was done here https://github.com/odoo/odoo/pull/99856, but when copying multiple attachments it failed For example in the case of a mass.mailing sending 2 attachments, indexes every attachment, taking forever and never finishing. Desired behavior after PR is merged: On copy of multiple attachment, avoid indexing every time --- I confirm I have signed the CLA and read the PR guideline
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: The original fix was done here https://github.com/odoo/odoo/pull/99856, but when copying multiple attachments it failed For example in the case of a mass.mailing sending 2 attachments, indexes every attachment, taking forever and never finishing. Desired behavior after PR is merged: On copy of multiple attachment, avoid indexing every time --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152219
In https://github.com/odoo/odoo/commit/e0491c1a623ffec19ed563679f853cc6d1c56d03 we changed the spacing of the activity button to dissociate it from buttons that are "message/communication" oriented. This spacing was unwanted so we need to revert it back. task-3730089 | Before | After | | --- | --- | | |
Original PR description
In https://github.com/odoo/odoo/commit/e0491c1a623ffec19ed563679f853cc6d1c56d03 we changed the spacing of the activity button to dissociate it from buttons that are "message/communication" oriented. This spacing was unwanted so we need to revert it back. task-3730089 | Before | After | | --- | --- | | | | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153100
Issue: - When a Helpdesk ticket is associated with a partner, this association is not being correctly linked in the Timesheet module. As a result, when attempting to group Timesheet entries by partner, the grouping is inaccurate. - The issue is caused by the _compute_partner_id not being triggered due to the partner_id being set in the _timesheet_preprocess method. Steps To Reproduce: - Go to Helpdesk - Click on any project with the timesheet option enabled. - Click on new - Add title,
Original PR description
Issue: - When a Helpdesk ticket is associated with a partner, this association is not being correctly linked in the Timesheet module. As a result, when attempting to group Timesheet entries by partner, the grouping is inaccurate. - The issue is caused by the _compute_partner_id not being triggered due to the partner_id being set in the _timesheet_preprocess method. Steps To Reproduce: - Go to Helpdesk - Click on any project with the timesheet option enabled. - Click on new - Add title, customer and timesheet hours - Go to Timesheet - Group by 'partner'> the customer is not there Solution: - remove the lines where partner_id is set in '_timesheet_preprocess'. - Test link to this PR: https://github.com/odoo/enterprise/pull/54373 opw-3667921 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153740 Forward-Port-Of: odoo/odoo#153026
Consider the case that we attach invoices to the followup. We only attach invoices that have previously been printed / generated. (Except if someone attaches a custom file which could be whatever.) Currently: 1. During the generation of the followup report we basically just regenerate the invoices by calling the invoice template. 2. The PDFs that are added in the manual followup wizzard are not added to the generated PDF. Problem: (Reproduce at the bottom) Point (1.) is a problem in
Original PR description
Consider the case that we attach invoices to the followup. We only attach invoices that have previously been printed / generated. (Except if someone attaches a custom file which could be whatever.)…
Consider the case that we attach invoices to the followup. We only attach invoices that have previously been printed / generated. (Except if someone attaches a custom file which could be whatever.)
Currently:
1. During the generation of the followup report we basically just regenerate the invoices by calling the invoice template.
2. The PDFs that are added in the manual followup wizzard are not added to the generated PDF.
Problem: (Reproduce at the bottom)
Point (1.) is a problem in case the template does not reflect the actual printed invoice. This can happen since the PDF output may also be altered during render time (by overwriting '_render_qweb_pdf_prepare_streams'). This is i.e. a problem for l10n_ch. There, a QR code is appended to the invoice PDF only during render time. This QR code does not appear in the followup report since it is not part of the template. Point (2.) may lead to missing invoices in the generated PDF.
After this commit:
The actual PDF (that was generated previously) is attached to the invoice. Thus i.e. the QR code appears in l10n_ch.
In the process Point (2.) was also solved. In case the manually added files are not PDFs they are silently dropped.
Reproduce
1. Install l10n_ch
2. Select 'CH Company'
3. Create an Invoice
* Due Date: in the past
* Customer: Easy Clean Lausanne (A Swiss company)
5. Print the PDF. Check that the QR code is appended to the invoice
6. Go to follow-up reports for Easy Clean Lausanne and follow up with 'Print' option. Ensure 'Attach Invoices' is checked. Add some PDF file manually. Click "Print"
7. The invoice is appended to the follow-up report but w/o QR code. The PDF that was manually added does not appear in the report at all.
task-3472962
Forward-Port-Of: odoo/enterprise#56451
Forward-Port-Of: odoo/enterprise#53836Since 16.3 ticket_id and ticket_ref don't have the same value, so it won't make sense to show public user ticket_id when they submit tickets anymore. 1) Value will be wrong if ticket_ref sequence has changed 2) They can not access tickets from the portal anyway since they are not portal users. opw-3708995 Forward-Port-Of: odoo/enterprise#56041
Original PR description
Since 16.3 ticket_id and ticket_ref don't have the same value, so it won't make sense to show public user ticket_id when they submit tickets anymore. 1) Value will be wrong if ticket_ref sequence has changed 2) They can not access tickets from the portal anyway since they are not portal users. opw-3708995 Forward-Port-Of: odoo/enterprise#56041
Issue: - When a Helpdesk ticket is associated with a partner, this association is not being correctly linked in the Timesheet module. As a result, when attempting to group Timesheet entries by partner, the grouping is inaccurate. - The issue is caused by the '_compute_partner_id' not being triggered due to the 'partner_id' being set in the '_timesheet_preprocess' method. Steps To Reproduce: - Go to Helpdesk - Click on any project with the timesheet option enabled. - Click on new
Original PR description
Issue: - When a Helpdesk ticket is associated with a partner, this association is not being correctly linked in the Timesheet module. As a result, when attempting to group Timesheet entries by partner, the grouping is inaccurate. - The issue is caused by the '_compute_partner_id' not being triggered due to the 'partner_id' being set in the '_timesheet_preprocess' method. Steps To Reproduce: - Go to Helpdesk - Click on any project with the timesheet option enabled. - Click on new - Add title, customer and timesheet hours - Go to Timesheet - Group by 'partner'> the customer is not there Solution: - remove the lines where partner_id is set in '_timesheet_preprocess'. - This test is linked to this PR https://github.com/odoo/odoo/pull/153026 opw-3667921 Forward-Port-Of: odoo/enterprise#56446 Forward-Port-Of: odoo/enterprise#54373
runbot task: 55516 Forward-Port-Of: odoo/enterprise#56168 Forward-Port-Of: odoo/enterprise#55732
Original PR description
runbot task: 55516 Forward-Port-Of: odoo/enterprise#56168 Forward-Port-Of: odoo/enterprise#55732
**Current behavior:** Changing the language of the database does not translate the operation_type field in the stock.report model's views. --- **Expected behavior:** The field operation_type gets translated in the stock.report model's views. --- **Steps to reproduce:** 1. In the Inventory application, use the menu bar to navigate to 'Reporting' -> 'Warehouse Analysis' 2. Change the database/user language to something non-English 3. Issue can be observed in the pivot v
Original PR description
**Current behavior:** Changing the language of the database does not translate the operation_type field in the stock.report model's views. --- **Expected behavior:** The field operation_type gets translated in the stock.report model's views. --- **Steps to reproduce:** 1. In the Inventory application, use the menu bar to navigate to 'Reporting' -> 'Warehouse Analysis' 2. Change the database/user language to something non-English 3. Issue can be observed in the pivot view (first column) --- **Cause of the issue:** The stock.report model stores the operation_type field as a Char field type. --- **Fix:** Add an operation_type_id (M2o) field and use it to replace all references to the old operation_type field. --- opw-3663227 Forward-Port-Of: odoo/enterprise#55907 Forward-Port-Of: odoo/enterprise#53802
description : When a user is trying to deisgn a new template, upon quitting studio mode, an error is trigger, or in some case the studio page is not even opened and crashes. steps to reproduce: on any saas-17.1 -master version - open quality app - select configuration then quality worksheet template - select Design template on any worksheet - click on the 'close' button to leave studio an error message is displayed. expected behavior: studio is closed correctly and the changes are sa
Original PR description
description : When a user is trying to deisgn a new template, upon quitting studio mode, an error is trigger, or in some case the studio page is not even opened and crashes. steps to reproduce: on…
description : When a user is trying to deisgn a new template, upon quitting studio mode, an error is trigger, or in some case the studio page is not even opened and crashes. steps to reproduce: on any saas-17.1 -master version - open quality app - select configuration then quality worksheet template - select Design template on any worksheet - click on the 'close' button to leave studio an error message is displayed. expected behavior: studio is closed correctly and the changes are saved source of the issue: The worksheet_id was added to the context in generic use case to handle a fsm specific one. This was done in order to let the opportunity to later on use the same logic on other module if needed. This id being present in the context is triggering the fsm specific steps when it is unneeded. Solution: Remove the id from the generic method 'get_x_model_from_action' and add it in the overwrite inside the fsm module. note: No tests were added because the only way to test this use case is to add a js tour, which seemed a bit overkill for such a small fix. opw-3730854 affected version: saas-17.1 - master Forward-Port-Of: odoo/enterprise#56537
Currently, a log error is occurring from [1] and [2] due to adding two msgids instead of one there in the 'es_419.po' file. This is because the recently refactored code https://github.com/odoo/enterprise/commit/c2a5c5950cf702c6ed77d8b94c7dfece3f127dc8 updated translations but added an extra msgid at [1] and [2]. Error ``` KeyError: ('mi', 'mi') File "polib.py", line 1491, in process (action, state) = self.transitions[(symbol, self.current_state)] OSError: Syntax error in po fil
Original PR description
Currently, a log error is occurring from [1] and [2] due to adding two msgids instead of one there in the 'es_419.po' file. This is because the recently refactored code…
Currently, a log error is occurring from [1] and [2] due to adding two msgids instead of one
there in the 'es_419.po' file. This is because the recently refactored code https://github.com/odoo/enterprise/commit/c2a5c5950cf702c6ed77d8b94c7dfece3f127dc8
updated translations but added an extra msgid at [1] and [2].
Error
```
KeyError: ('mi', 'mi')
File "polib.py", line 1491, in process
(action, state) = self.transitions[(symbol, self.current_state)]
OSError: Syntax error in po file (line 281)
File "odoo/tools/translate.py", line 1660, in _get_code_translations
p = CodeTranslations._read_code_translations_file(fileobj, filter_func)
File "odoo/tools/translate.py", line 1647, in _read_code_translations_file
reader = TranslationFileReader(fileobj, fileformat='po')
File "odoo/tools/translate.py", line 636, in TranslationFileReader
return PoFileReader(source)
File "odoo/tools/translate.py", line 691, in __init__
self.pofile = polib.pofile(source.read().decode())
File "polib.py", line 130, in pofile
return _pofile_or_mofile(pofile, 'pofile', **kwargs)
File "polib.py", line 78, in _pofile_or_mofile
instance = parser.parse()
File "polib.py", line 1352, in parse
self.process(keywords[tokens[0]])
File "polib.py", line 1495, in process
raise IOError('Syntax error in po file (line %s)' %
```
[1]-https://github.com/odoo/enterprise/blob/8e8e5b2f01c75f0131d8248997fa4059777e3fa1/l10n_ar_reports/i18n/es_419.po#L280-L281 [2]-https://github.com/odoo/enterprise/blob/8e8e5b2f01c75f0131d8248997fa4059777e3fa1/l10n_ar_reports/i18n/es_419.po#L459-L460
sentry-4963679418
Forward-Port-Of: odoo/enterprise#56362Before this commit, and because of [1], the full action context was used to create or write any oject that edit_view would use. This caused two types of issues: - Checking the view integrity (_check_xml) sometimes crashed because the context keys (for modifiers) were present and return something else than a Boolean - creating objects with "default_" keys in the context ultimately failed, at best with a crash, at worst it ended up creating object with the wrong data. After this commit, we
Original PR description
Before this commit, and because of [1], the full action context was used to create or write any oject that edit_view would use. This caused two types of issues: - Checking the view integrity (_check_xml) sometimes crashed because the context keys (for modifiers) were present and return something else than a Boolean - creating objects with "default_" keys in the context ultimately failed, at best with a crash, at worst it ended up creating object with the wrong data. After this commit, we still retrieve stuff (the view, in particular) with the full context to have symmetry with the original get_view of Studio, but we write and create things with a cleaned context. opw-3718769 opw-3719815 opw-3703559 opw-3702620 opw-3702360 opw-3698111 opw-3698108 opw-3702084 [1]: https://github.com/odoo/enterprise/pull/54552/ Forward-Port-Of: odoo/enterprise#56466 Forward-Port-Of: odoo/enterprise#56372
Steps: - Open Field service - Go to planning menu - Set menu planning by user - Create task from user line Issue: - In the assignee field user does not set by default. Cause: - Calling `default_get` super method before finding fsm project in `industry_fsm` module sets a current user to task because default_get method treat that task a private task and because of that current user is default assigned in most of fsm action. Fix: - Find fsm project and set it in context before calli
Original PR description
Steps: - Open Field service - Go to planning menu - Set menu planning by user - Create task from user line Issue: - In the assignee field user does not set by default. Cause: - Calling `default_get` super method before finding fsm project in `industry_fsm` module sets a current user to task because default_get method treat that task a private task and because of that current user is default assigned in most of fsm action. Fix: - Find fsm project and set it in context before calling super method so current user does not get assigned for fsm project's tasks. task-3502839 Forward-Port-Of: odoo/enterprise#56396 Forward-Port-Of: odoo/enterprise#48051
This commit fixes the notebook compiler of the form editor. Since some views define invisible fields directly inside a notebook, the compiler was wrong when trying to match the xpath of a notebook tab with the corresponding node from the compiled Notebook component. This created issues, such as incorrect or null xpaths, preventing to edit some tabs and pages, or crashing when adding an element. opw-3672498 Forward-Port-Of: odoo/enterprise#56257 Forward-Port-Of: odoo/enterprise#56057
Original PR description
This commit fixes the notebook compiler of the form editor. Since some views define invisible fields directly inside a notebook, the compiler was wrong when trying to match the xpath of a notebook tab with the corresponding node from the compiled Notebook component. This created issues, such as incorrect or null xpaths, preventing to edit some tabs and pages, or crashing when adding an element. opw-3672498 Forward-Port-Of: odoo/enterprise#56257 Forward-Port-Of: odoo/enterprise#56057
## Description: Previously, the enter key didn't function as expected when interacting with the spreadsheet selector dialog or template dialog. This PR resolves the issue by implementing the use of the useHotkey hook, allowing the enter key to efficiently open the spreadsheet when needed. TaskID: [3640162](https://www.odoo.com/web#id=3640162&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#56294 Forward-Port-Of: odoo/ente
Original PR description
## Description: Previously, the enter key didn't function as expected when interacting with the spreadsheet selector dialog or template dialog. This PR resolves the issue by implementing the use of the useHotkey hook, allowing the enter key to efficiently open the spreadsheet when needed. TaskID: [3640162](https://www.odoo.com/web#id=3640162&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#56294 Forward-Port-Of: odoo/enterprise#53485
- Better handling of errors in case of undistributed negative lines. - Prevent sending of empty invoice/order/global invoice CFDI - Better mapping of negative lines on positive ones. - Allow adding credit note with invoices inside a global invoice. - Allow auto refund of the global invoice when asking an invoice for a refunded order Forward-Port-Of: odoo/enterprise#56067 Forward-Port-Of: odoo/enterprise#55064
Original PR description
- Better handling of errors in case of undistributed negative lines. - Prevent sending of empty invoice/order/global invoice CFDI - Better mapping of negative lines on positive ones. - Allow adding credit note with invoices inside a global invoice. - Allow auto refund of the global invoice when asking an invoice for a refunded order Forward-Port-Of: odoo/enterprise#56067 Forward-Port-Of: odoo/enterprise#55064
Bug === When we show the sample data of documents, it will choose a random value for the selection field. But document use a special option to make the browser generate the thumbnail of PDFs and then save it on the record. So, without this rule, it will try to update the record if "client_generated" has been chosen. Task-3697924 See odoo/odoo/pull/152490 Forward-Port-Of: odoo/enterprise#56033
Original PR description
Bug === When we show the sample data of documents, it will choose a random value for the selection field. But document use a special option to make the browser generate the thumbnail of PDFs and then save it on the record. So, without this rule, it will try to update the record if "client_generated" has been chosen. Task-3697924 See odoo/odoo/pull/152490 Forward-Port-Of: odoo/enterprise#56033
Steps to reproduce: --- 1. Go to Website 2. Click on Edit 3. Place an 'Image - text' block 4. Place an 'Online Appointment' block 5. Select the text on the button 6. In the edit menu, click on edit link 7. Change the link to /website/info 8. Click on save 9. Click on the button 10. Error pops up before redirection 11. Traceback in the console Cause of the issue: --- When editing the text on the button to have a different link, it puts a link tag in the button. When clicking th
Original PR description
Steps to reproduce: --- 1. Go to Website 2. Click on Edit 3. Place an 'Image - text' block 4. Place an 'Online Appointment' block 5. Select the text on the button 6. In the edit menu, click on edit link 7. Change the link to /website/info 8. Click on save 9. Click on the button 10. Error pops up before redirection 11. Traceback in the console Cause of the issue: --- When editing the text on the button to have a different link, it puts a link tag in the button. When clicking the link inside the button, the target is not the same as if it was the button. opw-3610062 Forward-Port-Of: odoo/enterprise#53147
Most (if not all) dashboards have monetary amounts. They are formatted with the main company currency format. Before this commit, a RPC was made to fetch the company currency. With this commit, the dashboard is loaded with the currency. It saves one network request and a full spreadsheet evaluation (which would have occured after the request is done) Task: 3709466 Forward-Port-Of: odoo/enterprise#55415
Original PR description
Most (if not all) dashboards have monetary amounts. They are formatted with the main company currency format. Before this commit, a RPC was made to fetch the company currency. With this commit, the dashboard is loaded with the currency. It saves one network request and a full spreadsheet evaluation (which would have occured after the request is done) Task: 3709466 Forward-Port-Of: odoo/enterprise#55415
Purpose: -------- This commit adds some tests for the room application which currently has almost none. It also fixes some issues that were pointed out by writing these tests: - Fix reactivity of the booking form view: when a notification of a booking update was received during the edition of a booking, its duration was changed in the sidebar but not in this form view. - Fix luxon locale desync: since the redesign of the frontend view, the locale used when loading the existing bookings wa
Original PR description
Purpose: -------- This commit adds some tests for the room application which currently has almost none. It also fixes some issues that were pointed out by writing these tests: - Fix reactivity of the…
Purpose: -------- This commit adds some tests for the room application which currently has almost none. It also fixes some issues that were pointed out by writing these tests: - Fix reactivity of the booking form view: when a notification of a booking update was received during the edition of a booking, its duration was changed in the sidebar but not in this form view. - Fix luxon locale desync: since the redesign of the frontend view, the locale used when loading the existing bookings was not the same as the one used after it. - Fix current week in the form view: the week was not updated when clicking on a booking in the sidebar while already in the form view. - Fix remaining time flicker: when a booking ended, the remaining time could be minus 1 second for a split second. - Fix remaining time reactivity: when a booking started immediately after that another one ended, the remaining time shown was not updated at the same time than the sidebar and current booking title. Task-3609006 Forward-Port-Of: odoo/enterprise#56456 Forward-Port-Of: odoo/enterprise#51351
Purpose ======= Whether the visitor was a man or a woman, the message sent contained pronoun : he. To avoid this, the new sentence will no longer have a pronoun. task: 3673432 Forward-Port-Of: odoo/enterprise#56404 Forward-Port-Of: odoo/enterprise#54546
Original PR description
Purpose ======= Whether the visitor was a man or a woman, the message sent contained pronoun : he. To avoid this, the new sentence will no longer have a pronoun. task: 3673432 Forward-Port-Of: odoo/enterprise#56404 Forward-Port-Of: odoo/enterprise#54546
The test classes should not be standard: it makes the test run in l10n builds, while we only expect them to be tested on external builds. So, we can have issues with the server from the government not responding which causes errors on l10n builds It also causes issues in 16.4+ where the request is not accepted. Linked to runbot error 23358, 57019 Forward-Port-Of: odoo/enterprise#56274
Original PR description
The test classes should not be standard: it makes the test run in l10n builds, while we only expect them to be tested on external builds. So, we can have issues with the server from the government not responding which causes errors on l10n builds It also causes issues in 16.4+ where the request is not accepted. Linked to runbot error 23358, 57019 Forward-Port-Of: odoo/enterprise#56274
Create a monetary on a model. In studio, remove the currency_field for that field. Note that the currency field would have been create automatically since commit [1] Try to export the studio customization module. Before this commit, there was crash, because the code that retrieves the currency_field was somewhat erroneous and a recordset of ir.model.fields was joined to a recordset of ir.model. After this commit, there is no crash and we export the value for the currency_field of the mo
Original PR description
Create a monetary on a model. In studio, remove the currency_field for that field. Note that the currency field would have been create automatically since commit [1] Try to export the studio customization module. Before this commit, there was crash, because the code that retrieves the currency_field was somewhat erroneous and a recordset of ir.model.fields was joined to a recordset of ir.model. After this commit, there is no crash and we export the value for the currency_field of the monetary opw-3677016 Forward-Port-Of: odoo/enterprise#56408
## Description Domains of the form ```python [('stored_Many2X.id', '=/!=/in/not in', list_of_ids)] ``` will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table. There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly
Original PR description
## Description
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly referencing the `field` from the `model`. So in some cases using an explicit `.id` would be a wanted, if the intention was to apply the `ir.rule`.
But in the context of domain in `ir.rule` themselves, the previous concern isn't of application, as `ir.rule` are generated in a `sudo` context, therefor no `ir.rule` are applied.
## Fix
Remove the `.id` from left leafs of domains from `ir.rule`
task-3735923
Forward-Port-Of: odoo/enterprise#56263Have a company partner with overdue invoices Create a followup contact for the partner Open the followup report Send followup by post (snailmail) Issue: Letter will be generated without accounting information: the table with overdue invoices will be empty This occurs because the letter will be created with the followup contact being both partner and receiver opw-3631639 Forward-Port-Of: odoo/enterprise#52614
Original PR description
Have a company partner with overdue invoices Create a followup contact for the partner Open the followup report Send followup by post (snailmail) Issue: Letter will be generated without accounting information: the table with overdue invoices will be empty This occurs because the letter will be created with the followup contact being both partner and receiver opw-3631639 Forward-Port-Of: odoo/enterprise#52614
Sometimes, when handling export of VAT Book (libros) by getting all the lines from the tax report, some of the line might not be ordered as expected. If a tax/surcharge line appear in the list before the base line, this will result in a KeyError when trying to access sheet_line_vals of the id because they have not been created yet. This commit aims to fix that, and also refactor this part of the code to be more clear, clean, & error-proof in the future. An handler for error in the common erro
Original PR description
Sometimes, when handling export of VAT Book (libros) by getting all the lines from the tax report, some of the line might not be ordered as expected. If a tax/surcharge line appear in the list before the base line, this will result in a KeyError when trying to access sheet_line_vals of the id because they have not been created yet. This commit aims to fix that, and also refactor this part of the code to be more clear, clean, & error-proof in the future. An handler for error in the common error place (KeyError) is also written for similar problems we might encounter in the future. task-id: 3703023 Forward-Port-Of: odoo/enterprise#55249
There was an issue with the `copy` feature of the `/clipboard` command. When pasted, the content was formatted as if it was not originally `Odoo` content (and some style features were removed, like the font color). To remedy that, instead of using the `clipboard` API, the deprecated `execCommand('copy')` function is used so that the `copy` handler of the `OdooEditor` is properly triggered and the html content is properly set under the `text/odoo-editor` custom "MIME type". Remark: it
Original PR description
There was an issue with the `copy` feature of the `/clipboard` command. When
pasted, the content was formatted as if it was not originally `Odoo` content
(and some style features were removed, like the font color).
To remedy that, instead of using the `clipboard` API, the deprecated
`execCommand('copy')` function is used so that the `copy` handler of the
`OdooEditor` is properly triggered and the html content is properly set under
the `text/odoo-editor` custom "MIME type".
Remark: it is not possible use that "fake" "MIME type" to write data directly to
the clipboard because it is not officially recognized (will produce an error).
task-3700875
Forward-Port-Of: odoo/enterprise#55127Im timesheet_grid when starting a timer in the kanban view, the dropdowns are displayed behind the o_kanban_record, making it impossible to use. This is due to a change made on the pinned_header z-index introduced in commit[1]. This commit applies a z-index-1 on the pinned_header element, making the dropdowns contained inside this div being able to be displayed above the kanban cards. [1]: https://github.com/odoo/enterprise/commit/7b1f18398d0d1f66269d742ef2441ef2bb41f7e6 task-3684460
Original PR description
Im timesheet_grid when starting a timer in the kanban view, the dropdowns are displayed behind the o_kanban_record, making it impossible to use. This is due to a change made on the pinned_header z-index introduced in commit[1]. This commit applies a z-index-1 on the pinned_header element, making the dropdowns contained inside this div being able to be displayed above the kanban cards. [1]: https://github.com/odoo/enterprise/commit/7b1f18398d0d1f66269d742ef2441ef2bb41f7e6 task-3684460 | Before | | :----: | |  | | After | | | Forward-Port-Of: odoo/enterprise#56330 Forward-Port-Of: odoo/enterprise#54313
When the user confirms the order and a WhatsApp message is sent using cron this error is produced. Steps to produce: - Install `whatsapp_website_sale` - keep the customer's phone number invalid (E.g. `+1 555-555-5555`) - from the website, add some products and proceed to checkout - try to pay for that order - the error will be produced as an invalid phone number Problem:- When a WhatsApp message is sent using `force_send_by_cron=True` then it must not raise any user error in between
Original PR description
When the user confirms the order and a WhatsApp message is sent using cron this error is produced. Steps to produce: - Install `whatsapp_website_sale` - keep the customer's phone number invalid (E.g.…
When the user confirms the order and a WhatsApp message is sent using cron this error is produced. Steps to produce: - Install `whatsapp_website_sale` - keep the customer's phone number invalid (E.g. `+1 555-555-5555`) - from the website, add some products and proceed to checkout - try to pay for that order - the error will be produced as an invalid phone number Problem:- When a WhatsApp message is sent using `force_send_by_cron=True` then it must not raise any user error in between regardless of a single or multiple records. But for obtaining the value `formatted_number_wa`in `_send_whatsapp_template`, `raise_exception` is `False` only in the case of multiple records and not in the case of a single record, even if the record is sent using cron. Solution:- `raise_exception` must be `False` if `batch_mode` or `force_send_by_cron` is `True`. While calculating `formatted_number_wa` using `wa_phone_validation` the `raise_exception` must be false if the message is sent using cron. Task - 3662747 Forward-Port-Of: odoo/enterprise#53495
Bug === Before, we needed to mention the author of the Tweet we are replying to, in order to make the Tweet looks like a reply on Twitter. It seems not needed anymore and cause double mention issue (only on the Odoo side, Twitter seems to show only one mention). Task-3686630 Forward-Port-Of: odoo/enterprise#54674
Original PR description
Bug === Before, we needed to mention the author of the Tweet we are replying to, in order to make the Tweet looks like a reply on Twitter. It seems not needed anymore and cause double mention issue (only on the Odoo side, Twitter seems to show only one mention). Task-3686630 Forward-Port-Of: odoo/enterprise#54674
Before this commit: GST treatment for composition was under the domain of b2c* which is not the correct domain for composition UIN Holder treatment was inconsistently placed After this commit: composition GST treatment is fixed correctly under b2b and fixed the consistency for UIN Holder in l10n_in_reports* Forward-Port-Of: odoo/enterprise#56350 Forward-Port-Of: odoo/enterprise#56225
Original PR description
Before this commit: GST treatment for composition was under the domain of b2c* which is not the correct domain for composition UIN Holder treatment was inconsistently placed After this commit: composition GST treatment is fixed correctly under b2b and fixed the consistency for UIN Holder in l10n_in_reports* Forward-Port-Of: odoo/enterprise#56350 Forward-Port-Of: odoo/enterprise#56225
In #48767, we introduced the collapsing of a certain side panel feature relying on Bootstrap. Bootstrap apparenty has an internal "popote" to make the target node fold and unfold and one of our tests actually tests against this internal popote. Unfortunately, the test is not reliable and from a computer to the other or even depending on the browser you use, it does not behave consistently. This commit removes the unreliable step as it does not test our own codebase. Task: 3736963 Forw
Original PR description
In #48767, we introduced the collapsing of a certain side panel feature relying on Bootstrap. Bootstrap apparenty has an internal "popote" to make the target node fold and unfold and one of our tests actually tests against this internal popote. Unfortunately, the test is not reliable and from a computer to the other or even depending on the browser you use, it does not behave consistently. This commit removes the unreliable step as it does not test our own codebase. Task: 3736963 Forward-Port-Of: odoo/enterprise#56291