Wednesday, November 27, 2024
33 changes · saas-17.4
Enhancements to existing features
The point of sale product configurator now keeps one option selected for each required product attribute, matching normal radio button behavior. This prevents sales staff from adding products without a valid variant, reducing order mistakes at checkout.
Original PR description
Before this commit: - In the product configurator popup, it was possible to deselect a product attribute and add a product without a variant to the cart, which violated the standard behavior of radio buttons. Following this commit : - Product attributes in the product configurator popup can no longer be deselected aligning with the expected functionality of radio buttons. task- 4285309
Resolved issues and error corrections
Fixed a point-of-sale issue where pressing backspace twice while entering a percentage down payment on a quotation could cause an error. This makes the sales flow more reliable for cashiers handling quotation payments in POS.
Original PR description
Steps to reproduce : --------------------------- - Install the point_of_sale and sales module. - Set downpayment on the shop and open session. - Press quotation/orders action button. - Open any quotation try apply percentage downpayment. - Try to press backspace twice. Issue : --------- The number buffer would be "" at starting but when we again press backspace it will become null as mentioned from number buffer services which was directly passed to parseFloat function. Cause : ---------- The parse float function applies startsWith function which won't be there if value is null. Fix : ------ Instead of passing buffer directly now just send buffer to parse if it exist else send "" instead of null.
Miscellaneous changes
This commit fixes a bug introduced in the PR ( https://github.com/odoo/odoo/pull/186434 ). This PR aims to batch operations on svls by grouping based on products. However, it didn't take into account the possibility where svls could belong to different companies. This would lead to a singleton error upon referencing the field "anglo_saxon_accounting". To fix the problem, grouping svls must be done based on a composite key based on product and value of "anglo_saxon_accounting". --- I con
Original PR description
This commit fixes a bug introduced in the PR ( https://github.com/odoo/odoo/pull/186434 ). This PR aims to batch operations on svls by grouping based on products. However, it didn't take into account the possibility where svls could belong to different companies. This would lead to a singleton error upon referencing the field "anglo_saxon_accounting". To fix the problem, grouping svls must be done based on a composite key based on product and value of "anglo_saxon_accounting". --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188680
The self-order product page now displays the currency symbol on product cards. This helps customers clearly understand prices before ordering, reducing confusion during the buying flow.
Original PR description
Before this commit: ========== - The currency symbol was not visible on the product card on the self-order product page. After this commit: ========== - The currency symbol is now visible on the product card on the self-order product page. task-4342039
A test for the web date picker was adjusted so it no longer fails when the picker takes slightly longer to open. This helps keep automated checks stable and reduces false alarms during development, without changing the user-facing product.
Original PR description
This commit fixes a test which sometimes timeout. To quickly explain, the test tries to open the date picker popover and it succeeds almost everytime but it happens that the popover takes more time than the usual.
A visual issue caused the language button to appear twice when hovering over interface views. This fix keeps the button display consistent, reducing confusion for users working in the web interface.
Original PR description
The button is doubled because the visibility is overriden. Let's force it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes shared appointment availability calendars easier to read by better distinguishing past time slots from non-business hours. It also prevents today's calendar view from visually overflowing when past hours are shaded, improving scheduling clarity for users.
Original PR description
Purpose ======= Fix the calendar slots selection display when sharing appointment availabilities. Specification ============= The working hours have recently been added to the user's calendar. To highlight those, the non-business hours cells are grayed out (from 9am to 5pm). Following this change, it is now difficult to differentiate the non-business hours cells from the "Share Availabilities" gray overlay set on all the past cells. Fixing that by darkening a bit the color of the past cells when sharing availabilities. Additionally, for today, a div with a computed height was added to gray out cells before the current time. This div is now pushing the non-business hours divs which makes them overflow the day display. Fixing that by changing today's past hours div to position absolute. related commit: odoo/odoo@09ddd9f46c0d7528cb0138af283f6ec4f388a445 Task-4337795
Studio now only offers timeline scale options that are allowed by the underlying planning view. This prevents users from selecting an unsupported expanded month view that could cause the planning schedule to fail when switching views.
Original PR description
Steps to reproduce ================== - Go to planning - Open studio - Change the default scale to Month (expanded) - Close studio - Switch to Schedule > By Role => Cannot destructure property 'defaultRange' of 'metaData.scales[scaleId]' Cause of the issue ================== The planning view has the scales attribute as `scales="day,week,month,year"`. month_3 is not part of the allowed scales. opw-4175183
This fixes an issue where a Gantt view could fail to open if its configured default time scale was not also listed among the allowed scales. The system now automatically includes that default scale, making scheduling views more reliable for users.
Original PR description
Steps to reproduce ================== - Have a gantt arch with a default_scale that is not part of scales ```xml <gantt scales="week,month" default_scale"day">...</gantt> ``` => Cannot destructure property 'defaultRange' of 'metaData.scales[scaleId]' Solution ======== If we set a default scale that is not part of the scales, add it to the list of allowed scales. opw-4175183
When users create a new spreadsheet from Documents, template options now display their names instead of appearing unnamed. This makes it easier to identify and choose the right spreadsheet template, reducing confusion during setup.
Original PR description
when creating a new spreadsheet in document, the user is prompted to either choose a blank spreadsheet or choose to create them from a template. The view didn't list the name of the template. This commit shows the name of the template Task: 4363974
Payroll users can now open the work entries Gantt view using the yearly scale without triggering an error. This resolves a configuration issue so annual planning and review of work entries works as expected.
Original PR description
…ntt view Steps: • Install the payroll app. • Open the work entries and set the Gantt view scale to "This year". • This will trigger an error. Cause of the issue: • In the Gantt view record, the year is missing in the scales attribute. Fix: • Added the year as an allowed scale. task-4351487
Steps to reproduce the bug: - Create storable products “P1,” “P2,” and “P3,” and update their quantities in stock. - Create a picking for one unit of P1 and P2. - Create a second picking for one unit of “P3.” - Mark both pickings as "To Do." - Set the move of P1 as "Picked." - Add both pickings to a new batch. - Try to validate the batch. - A wizard to create a backorder is triggered. - Discard the wizard Problem: The picking for P3 is detached from the batch. When validating th
Original PR description
Steps to reproduce the bug: - Create storable products “P1,” “P2,” and “P3,” and update their quantities in stock. - Create a picking for one unit of P1 and P2. - Create a second picking for one unit…
Steps to reproduce the bug: - Create storable products “P1,” “P2,” and “P3,” and update their quantities in stock. - Create a picking for one unit of P1 and P2. - Create a second picking for one unit of “P3.” - Mark both pickings as "To Do." - Set the move of P1 as "Picked." - Add both pickings to a new batch. - Try to validate the batch. - A wizard to create a backorder is triggered. - Discard the wizard Problem: The picking for P3 is detached from the batch. When validating the batch, empty or non-picked pickings are checked for detachment. Since the picking for P3 is not picked, it is marked to be detached: https://github.com/odoo/odoo/blob/7dda6bb92715ea25b2818a62fec5e646f3678b81/addons/stock_picking_batch/models/stock_picking_batch.py#L213-L214 https://github.com/odoo/odoo/blob/7dda6bb92715ea25b2818a62fec5e646f3678b81/addons/stock_picking_batch/models/stock_picking_batch.py#L201-L202 Afterward, we check if the other pickings can be validated. Since one move (P1) is picked and the other (P2) is not, the wizard to create a backorder is triggered, but the result is not checked, and detachment continues regardless: https://github.com/odoo/odoo/blob/7dda6bb92715ea25b2818a62fec5e646f3678b81/addons/stock_picking_batch/models/stock_picking.py#L125-L126 opw-4320352 Forward-Port-Of: odoo/odoo#187256
Steps: - Open any list view with more than 1 page - apply a limit if you don't have enough records - Toggle first record checkbox - Click on `o_pager_next` - Shift click on another record - Traceback The problem arises when you change page after using range-selection with the shift key. Indeed, range-selection uses `this.lastCheckedRecord`, which is the last record clicked on to start the selection, except that if you change page (and if you use a filter), thi
Original PR description
Steps:
- Open any list view with more than 1 page
- apply a limit if you don't have enough records
- Toggle first record checkbox
- Click on `o_pager_next`
- Shift click on another record
- Traceback
The problem arises when you change page after using range-selection with the shift key.
Indeed, range-selection uses `this.lastCheckedRecord`, which is the last record clicked on to start the selection, except that if you change page (and if you use a filter), this element may no longer be in the current page.
Currently, the code just checks that this element exists before attempting to create a selection by range.
The fix consists in checking that this element exists in the list of records before attempting anything.
opw-4284708
Forward-Port-Of: odoo/odoo#187244Steps to reproduce: - go to Employees>Configuration>Skill Types - create new skill or edit an existing one - change name or progress percentage of levels or add a new level - toggle default level - The fields revert to their original state, and only the toggle switch cause: it does not save other fields and just saves the default button when clicked solution: add this.props.record.model.root.save(); so it saves the record and not just the toggle button only. task-4223036 Forwa
Original PR description
Steps to reproduce: - go to Employees>Configuration>Skill Types - create new skill or edit an existing one - change name or progress percentage of levels or add a new level - toggle default level - The fields revert to their original state, and only the toggle switch cause: it does not save other fields and just saves the default button when clicked solution: add this.props.record.model.root.save(); so it saves the record and not just the toggle button only. task-4223036 Forward-Port-Of: odoo/odoo#188299 Forward-Port-Of: odoo/odoo#183369
Updated the redirect URL from `/web` to `/odoo` to align with the new URL structure introduced. Forward-Port-Of: odoo/odoo#188553
Original PR description
Updated the redirect URL from `/web` to `/odoo` to align with the new URL structure introduced. Forward-Port-Of: odoo/odoo#188553
**Problem**: This commit: https://github.com/odoo/odoo/commit/655e1ea63cf469937c53762e93f93da40b6b9099 breaks the behavior of the `list_renderer` when an autocomplete is present in the same view. Specifically, it prevents discarding a row when clicking outside the input. **Solution**: Revert the commit, as the issue it aimed to fix (opw-3180055) is now resolved by the addition of the "Search more" functionality, rendering the commit unnecessary. **Steps to reproduce**: 1. Open the *Pu
Original PR description
**Problem**: This commit: https://github.com/odoo/odoo/commit/655e1ea63cf469937c53762e93f93da40b6b9099 breaks the behavior of the `list_renderer` when an autocomplete is present in the same view. Specifically, it prevents discarding a row when clicking outside the input. **Solution**: Revert the commit, as the issue it aimed to fix (opw-3180055) is now resolved by the addition of the "Search more" functionality, rendering the commit unnecessary. **Steps to reproduce**: 1. Open the *Purchase* tab on a product form. 2. Add a vendor line (with or without selecting a vendor). 3. Focus on the vendor line, then click to add *Vendor Taxes*. 4. After selecting a tax, observe that the focus incorrectly shifts back to the vendor line instead of remaining on the *Vendor Taxes* input. opw-4263276 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187872
Return newly created leaves after calling `hr.leave._split_leaves()` to improve inheritability by other modules --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186948
Original PR description
Return newly created leaves after calling `hr.leave._split_leaves()` to improve inheritability by other modules --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186948
For an expense report paid by an employee, the bank account should be set on the employee form and be used to create the Journal Entry and in Register Payment Wizard. enterprise: https://github.com/odoo/enterprise/pull/71080 task-4206895 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188542 Forward-Port-Of: odoo/odoo#181870
Original PR description
For an expense report paid by an employee, the bank account should be set on the employee form and be used to create the Journal Entry and in Register Payment Wizard. enterprise: https://github.com/odoo/enterprise/pull/71080 task-4206895 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188542 Forward-Port-Of: odoo/odoo#181870
Following #156437, the destination location of a rule is now determined by the associated picking type destination. To keep compatibility with the old pull system (where each rule determined which destination it had, regardless of its picking type), a new field was added to force the destination defined on the rule to apply instead. This was done for `pull` and `pull_push` rules, as it was mainly the pull rules that were affected, but the `manufacture` case was overlooked, as it would break e
Original PR description
Following #156437, the destination location of a rule is now determined by the associated picking type destination. To keep compatibility with the old pull system (where each rule determined which destination it had, regardless of its picking type), a new field was added to force the destination defined on the rule to apply instead. This was done for `pull` and `pull_push` rules, as it was mainly the pull rules that were affected, but the `manufacture` case was overlooked, as it would break existing manufacture rules having a different destination on the rule than the one in the related picking type. To allow that back again, we enable that parameter to be set on `manufacture` rules as well. opw-4300074 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187898
Currently, customers are unable to invoice orders through a pos session if they use the Bulgarian localization. Steps to reproduce: ------------------- * Install **point_of_sale** and **l10n_bg** * Change the current company to the Bulgarian one * Set up a shop and open it * Make an order, select any customer * Select payment * Select the invoice option * Select payment method and validate > Observation: Traceback appears psycopg2.errors.CheckViolation: new row for relation "accou
Original PR description
Currently, customers are unable to invoice orders through a pos session if they use the Bulgarian localization. Steps to reproduce: ------------------- * Install **point_of_sale** and **l10n_bg** *…
Currently, customers are unable to invoice orders through a pos session if they use the Bulgarian localization. Steps to reproduce: ------------------- * Install **point_of_sale** and **l10n_bg** * Change the current company to the Bulgarian one * Set up a shop and open it * Make an order, select any customer * Select payment * Select the invoice option * Select payment method and validate > Observation: Traceback appears psycopg2.errors.CheckViolation: new row for relation "account_move_line" violates check constraint "account_move_line_check_accountable_required_fields" Why the fix: ------------ The constraints is violated because the value for account_id does not exist. https://github.com/odoo/odoo/blob/4601acea15feea4780269b4a333f18435904b684/addons/point_of_sale/models/pos_payment.py#L115-L117 We observe that `self.company_id.account_default_pos_receivable_account_id.id` is not set. This field belogns to the `account` module but can only be modified if the module `account_accountant` because of the group `group_account_readonly`. https://github.com/odoo/odoo/blob/4601acea15feea4780269b4a333f18435904b684/addons/point_of_sale/views/res_config_settings_views.xml#L163-L167 Other localizations do not have the issue as they set the default account through the data in `account`module. https://github.com/odoo/odoo/blob/4601acea15feea4780269b4a333f18435904b684/addons/l10n_au/data/account_chart_template_data.xml#L14 https://github.com/odoo/odoo/blob/4601acea15feea4780269b4a333f18435904b684/addons/l10n_au/data/account.account.template.csv#L8 opw-4279804 Forward-Port-Of: odoo/odoo#188018 Forward-Port-Of: odoo/odoo#186551
Issue: ====== `enter` command doesnt work properly for `pre` element inside list element. Steps to reproduce the issue: ============================= - Add a list - Add a code block with `/code` - Add sone text - Put the cursor at the end of the text - click `enter` - It adds a `br` element and puts the selection at the start. Origin of the issue: ==================== The `oEnter` function of the `pre` element is triggered which adds a `p` element just after the `pre` element in
Original PR description
Issue: ====== `enter` command doesnt work properly for `pre` element inside list element. Steps to reproduce the issue: ============================= - Add a list - Add a code block with `/code` - Add sone text - Put the cursor at the end of the text - click `enter` - It adds a `br` element and puts the selection at the start. Origin of the issue: ==================== The `oEnter` function of the `pre` element is triggered which adds a `p` element just after the `pre` element inside the same `li` element. Now in sanitiwe we unwrap the p elements inside `li` which leaves us with only a `br` after the `pre`. Since we put the selection at the start of the newly added then removed `p` element, the final selection will not behave correctly. Solution: ========= We single out the case when the parent element of the `pre` is a `li` and treat it as a break inside a `li`. task-4187676 Forward-Port-Of: odoo/odoo#188056 Forward-Port-Of: odoo/odoo#180268
The issue: In the mobile view of the website page /profile/users, the ranking table's content overflows the screen. How to reproduce the issue: -Install the website_profile and website_slides_survey modules. -Go to the /profile/users page in the website view. -Switch to mobile view. Explanation: Table overflowed on smaller screens due to missing responsive wrapper. opw-4120453 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of
Original PR description
The issue: In the mobile view of the website page /profile/users, the ranking table's content overflows the screen. How to reproduce the issue: -Install the website_profile and website_slides_survey modules. -Go to the /profile/users page in the website view. -Switch to mobile view. Explanation: Table overflowed on smaller screens due to missing responsive wrapper. opw-4120453 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183291
This commit fixes two issues with the editable grouped list view. In a group, click on a row to switch it into edition and edit an input field (e.g. a char). Do not blur the input. From this state, - clicking on the group header to close the group, or - clicking on "Add a line" to add a new record would both lead to the change being lost. This commit ensures the keep the change in those flows by correctly calling `leaveEditMode` before closing the group or adding the new record. opw~41
Original PR description
This commit fixes two issues with the editable grouped list view. In a group, click on a row to switch it into edition and edit an input field (e.g. a char). Do not blur the input. From this state, - clicking on the group header to close the group, or - clicking on "Add a line" to add a new record would both lead to the change being lost. This commit ensures the keep the change in those flows by correctly calling `leaveEditMode` before closing the group or adding the new record. opw~4174315 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#188611
Steps to reproduce the issue: 1. Navigate to the Events page. 2. Activate the Web Editor. 3. Attempt to edit the Event's short description. Issue: The short description of the event was previously not editable directly from the Events page. the reason behind that is they have used `t-out` instead of `t-field` in template. `t-out` lacks the necessary attributes to enable field updates. Solution: This PR adds the necessary attributes to the short description element, making it editable
Original PR description
Steps to reproduce the issue: 1. Navigate to the Events page. 2. Activate the Web Editor. 3. Attempt to edit the Event's short description. Issue: The short description of the event was previously not editable directly from the Events page. the reason behind that is they have used `t-out` instead of `t-field` in template. `t-out` lacks the necessary attributes to enable field updates. Solution: This PR adds the necessary attributes to the short description element, making it editable from the Events page. Updated the tour functionality to test the latest changes of Event's short description. task-4014153 Forward-Port-Of: odoo/odoo#187041 Forward-Port-Of: odoo/odoo#184263
Release notes: https://github.com/odoo/owl/releases/tag/v2.5.0 https://github.com/odoo/owl/releases/tag/v2.5.1 Forward-Port-Of: odoo/odoo#188406
Original PR description
Release notes: https://github.com/odoo/owl/releases/tag/v2.5.0 https://github.com/odoo/owl/releases/tag/v2.5.1 Forward-Port-Of: odoo/odoo#188406
Otherwise the patches remain in place, and it's possible for other modules to just assume things work if they happen to run after `test_website`. Forward-Port-Of: odoo/odoo#188608
Original PR description
Otherwise the patches remain in place, and it's possible for other modules to just assume things work if they happen to run after `test_website`. Forward-Port-Of: odoo/odoo#188608
Description of the issue/feature this PR addresses: - When working on this https://github.com/odoo/odoo/pull/186238 , few typos were discovered when populating data in demo database. - This pr fixes them - currently, the sample_ratio argument were not used in some methods [like this](https://github.com/odoo/odoo/blob/17.0/addons/mrp/populate/mrp.py#L363) instead values are hard coded. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forwa
Original PR description
Description of the issue/feature this PR addresses: - When working on this https://github.com/odoo/odoo/pull/186238 , few typos were discovered when populating data in demo database. - This pr fixes them - currently, the sample_ratio argument were not used in some methods [like this](https://github.com/odoo/odoo/blob/17.0/addons/mrp/populate/mrp.py#L363) instead values are hard coded. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187682
Oversight of odoo/enterprise#73209. Service invoices don't use the reason field at all (hidden in view) and thus will always fail the constraint. To fix it, disable the constraint for service invoices. opw-4354637 Forward-Port-Of: odoo/enterprise#74552
Original PR description
Oversight of odoo/enterprise#73209. Service invoices don't use the reason field at all (hidden in view) and thus will always fail the constraint. To fix it, disable the constraint for service invoices. opw-4354637 Forward-Port-Of: odoo/enterprise#74552
Problem: In a multi-company environment where a user has an employee record per company, the approval request will retrieve the incorrect employee record upon confirmation, which leads to an access error. Purpose: Upon confirming the approval request, the employee record from the same company as the request should be fetched, rather than retrieving the latest employee record made for the user. Steps to reproduce on Runbot: 1. Install Approvals and Employees 2. Create a default company
Original PR description
Problem: In a multi-company environment where a user has an employee record per company, the approval request will retrieve the incorrect employee record upon confirmation, which leads to an access…
Problem: In a multi-company environment where a user has an employee record per company, the approval request will retrieve the incorrect employee record upon confirmation, which leads to an access error. Purpose: Upon confirming the approval request, the employee record from the same company as the request should be fetched, rather than retrieving the latest employee record made for the user. Steps to reproduce on Runbot: 1. Install Approvals and Employees 2. Create a default company 3. Create a non-default company 4. Create a Test Employee user on the default company, enable multi-company rights, and create an employee record for the default company. Switch to the non-default company and create an employee record for the user. 5. Repeat Step 4 when creating a Test Manager user 6. On the employee record for Test Employee, set Test Manager as the manager on both companies. 7. Create an approval type on the default company and set "Manager is required approver" 8. Login as Test Employee and create an approval request for the approval type created in Step 7 on the default company 9. Submit the request and an AccessError occurs Note: Bug was not reproducible on previous versions because the record rule for Employee multi company rule for Employees module are different. opw-4212341 Forward-Port-Of: odoo/enterprise#71955
Romania does not use the 3-column trial balance report, instead they use a 4-column and 5-column variant. This commit adds the 4/5-column report as variants to the standard trial balance. The standard trial balance implementation has been changed to be easier to override and add column groups. task: 3810685 Forward-Port-Of: odoo/enterprise#74437 Forward-Port-Of: odoo/enterprise#59115
Original PR description
Romania does not use the 3-column trial balance report, instead they use a 4-column and 5-column variant. This commit adds the 4/5-column report as variants to the standard trial balance. The standard trial balance implementation has been changed to be easier to override and add column groups. task: 3810685 Forward-Port-Of: odoo/enterprise#74437 Forward-Port-Of: odoo/enterprise#59115
Apply [this fix] to templates introduced with [this commit]. The purpose is to prevent images that are the only child of their parent from taking too much space. Furthermore, fix the src path for some of these templates. [this fix]: https://github.com/odoo/odoo/commit/d5297a75f50022b406b226ebf4c300f4bd033c3d [this commit]: https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833 task-4178640 Forward-Port-Of: odoo/enterprise#74192
Original PR description
Apply [this fix] to templates introduced with [this commit]. The purpose is to prevent images that are the only child of their parent from taking too much space. Furthermore, fix the src path for some of these templates. [this fix]: https://github.com/odoo/odoo/commit/d5297a75f50022b406b226ebf4c300f4bd033c3d [this commit]: https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833 task-4178640 Forward-Port-Of: odoo/enterprise#74192
Steps ----- - Subscriptions > Configuration > Alerts. - Create an alert triggered when the stage goes from 'Initial' (placeholder) to 'In Progress', set 'Create next activity', chose Email as activity. - Create a subscription, confirm it. ** Multiple activities created in the chatter (1 would be expected) ** Cause ----- The `pre_domain_filter` of the `base.automation` is not set, leading to an activity being created every time a write happens on the sale order while it is in the `s
Original PR description
Steps ----- - Subscriptions > Configuration > Alerts. - Create an alert triggered when the stage goes from 'Initial' (placeholder) to 'In Progress', set 'Create next activity', chose Email as activity. - Create a subscription, confirm it. ** Multiple activities created in the chatter (1 would be expected) ** Cause ----- The `pre_domain_filter` of the `base.automation` is not set, leading to an activity being created every time a write happens on the sale order while it is in the `stage_to_id` stage. Change ----- Add a pre-domain/domain filter to only trigger actions when the stage changes. opw-4273625 Forward-Port-Of: odoo/enterprise#74292 Forward-Port-Of: odoo/enterprise#73601
- Add .pot base translation file. - Replace potentially unsafe `const_eval()` with a `json.loads()`. - Use the built-in methods for setting filename for received files. Forward-Port-Of: odoo/enterprise#74391 Forward-Port-Of: odoo/enterprise#74347
Original PR description
- Add .pot base translation file. - Replace potentially unsafe `const_eval()` with a `json.loads()`. - Use the built-in methods for setting filename for received files. Forward-Port-Of: odoo/enterprise#74391 Forward-Port-Of: odoo/enterprise#74347