Friday, April 25, 2025
26 changes · 18.0
Enhancements to existing features
This update adds clearer guidance for developers working with certificate and key records, making future maintenance easier. It also adds extra checks to make certificate handling more robust and less prone to errors.
Original PR description
The certificate and keys models were added in 18.0. A few docstrings could help devs using those methods. Furthermore, a few more checks and robustness were added. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fixes the displayed image for the Cofidis payment method. It ensures customers and staff see the correct branding during payment setup or checkout, avoiding confusion from an incorrect logo.
Original PR description
It seems it was an error of https://github.com/odoo/odoo/commit/077f6d449a660ee6961cce8174c9c6caaf5bc23f. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Problem --------- SPV requires the CIUS-RO xml. However, when selecting the "sending to SPV" uniquely in the move send wizard, it fails becuase it's missing the XML. Solution --------- When sending to SPV, generate the XML by default instead of doing nothing if it's not present. task-4720583 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207194 Forward-Port-Of: odoo/odoo#206828
Original PR description
Problem --------- SPV requires the CIUS-RO xml. However, when selecting the "sending to SPV" uniquely in the move send wizard, it fails becuase it's missing the XML. Solution --------- When sending to SPV, generate the XML by default instead of doing nothing if it's not present. task-4720583 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207194 Forward-Port-Of: odoo/odoo#206828
This fix makes automated checks for the restaurant point-of-sale wait until the floor plan is fully loaded before continuing. It helps prevent false test failures and supports more stable quality validation without changing day-to-day user workflows.
Original PR description
- SaveLastPreparationChangesTour To fix the error, add the three last steps to ensure floor plan is well rendered before close the browser. runbot-error-id~114344 - FinishResidualOrder Wait the screen floor is completely loaded before clicking on table 5 or the order can sometimes not be well loaded. runbot-error-id~161595 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
The HTML editor now removes unused bold, italic, underline, or strikethrough formatting markers when users move the cursor away. This prevents future text from unexpectedly inheriting formatting, making document editing more predictable.
Original PR description
**Behavior before this PR:** - Create a bold or italic tag using keyboard when selection is collapsed, leave it empty. - Change selection using arrow key. - Put cursor back where format tag was created. Notice that empty element is not removed and text is formatted when writing something. **Behavior after PR is merged:** - This PR makes sure that empty format element gets removed when changing selection. - Tag will not get removed if it's parent block element is empty. task-4240818 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes two restaurant point of sale test flows wait until the floor plan and related loading steps are fully ready before continuing. It reduces false test failures and helps keep restaurant POS quality checks stable without changing day-to-day user behavior.
Original PR description
- SaveLastPreparationChangesTour To fix the error, add a step Chrome.waitRequest() to wait the loader that can appears when time to load is too long. runbot-error-id~114344 - FinishResidualOrder Wait the screen floor is completely loaded before clicking on table 5 or the order can sometimes not be well loaded. runbot-error-id~161595 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
This fixes how tab spacing behaves in the HTML editor when used around text with a background color. Tabs inserted at the start of highlighted text no longer incorrectly inherit the background, while tabs inserted within or after the text still match the surrounding formatting.
Original PR description
**Current behaviour before PR:** When there is a text having background color, inserting a tab at the beginning of text creates a tab with background color. **Desired behaviour after PR is merged:** Now, if there is a text having background color, - Inserting tab at the beginning of text, tab will not have background color. - Inserting tab in the middle of a text, tab will have a background color corresponding to the text. - Inserting tab in the end of text, tab will have a background color corresponding to the text. task-4381135 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where very long blog or portal pages with comments could show a grey, unusable comment box over the page content. The hidden helper field used to size the real comment box is now kept fully out of sight, improving the visitor experience.
Original PR description
Scenario: create a long blog page article and enable comments Result: there is a grey unusable textarea with o-mail-Composer-fake over the blog content. Issue: in 7710c3331ebd22f8396870bd0731f8c1152d9c41 the fake textarea used to compute the height of the real textarea, had a position of -10000px, which make sense in the backend to make it hidden. But in 18.0 with 368eb78a9cedfce0802b64fd2782e1c018541e40 we use the backend composer on portal, where a page could be higher than 10000px and the fake textarea can be shown. Fix: hide it better (also to the left, and in case there was a 10000x10000 pixels page with comment at the bottom right, make it invisible). opw-4719975
Fixed an issue where product or picking descriptions could be missing from Chilean electronic delivery guides. The document now uses the line’s picking description, making delivery guide details clearer and preserving expected behavior.
Original PR description
When generating a 'Delivery Guide SII DTE 52 (CL)' the picking description was not always displayed. Steps to reproduce: ------------------- * Install l10n_cl_edi_stock * In Sales app, make a new quotation * Add a product and confirm * Click on the Delivery smart button * Click on the gear icon > Print > Delivery Guide SII DTE 52 (CL) > Observation: Why the fix: ------------ We now use the picking description of the line, which inherits from the product's picking description. This improves clarity, makes the line's description more useful, and preserves the original behavior. Enterprise pr: https://github.com/odoo/enterprise/pull/81920 opw-4596901 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Chilean electronic delivery guide now reliably shows the product or picking line description when printed. This helps users and customers understand delivered items more clearly while preserving the existing document flow.
Original PR description
When generating a 'Delivery Guide SII DTE 52 (CL)' the picking description was not always displayed. Steps to reproduce: ------------------- * Install l10n_cl_edi_stock * In Sales app, make a new quotation * Add a product and confirm * Click on the Delivery smart button * Click on the gear icon > Print > Delivery Guide SII DTE 52 (CL) > Observation: Why the fix: ------------ We now use the picking description of the line, which inherits from the product's picking description. This improves clarity, makes the line's description more useful, and preserves the original behavior. Community pr: https://github.com/odoo/odoo/pull/204764 opw-4596901
In Romania, when sending multiple invoices to e-Factura, if one invoice is rejected, the Send & Print wizard will raise a UserError at https://github.com/odoo/odoo/blob/9416ca8cb63fc53a862aa8533dfa60ba33506191/addons/account/wizard/account_move_send.py#L461 This causes the transaction to get rolled back, and any successfully-sent invoices to be lost. Solution: Commit after each invoice is sent. opw-4630496 Forward-Port-Of: odoo/odoo#205593
Original PR description
In Romania, when sending multiple invoices to e-Factura, if one invoice is rejected, the Send & Print wizard will raise a UserError at https://github.com/odoo/odoo/blob/9416ca8cb63fc53a862aa8533dfa60ba33506191/addons/account/wizard/account_move_send.py#L461 This causes the transaction to get rolled back, and any successfully-sent invoices to be lost. Solution: Commit after each invoice is sent. opw-4630496 Forward-Port-Of: odoo/odoo#205593
Add missing codes for payment methods --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207034
Original PR description
Add missing codes for payment methods --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207034
Steps to reproduce the bug: - Create a service product “S1” - Create a repair order: - In the parts: - Click on the catalog Problem: You can select a service product, whereas the products in the repair parts should be restricted to consumable-type products only: https://github.com/odoo/odoo/blob/f2923dec56b5ba2436bc244337c1e430a85e7e94/addons/stock/models/stock_move.py#L45-L48 opw-4687472 Forward-Port-Of: odoo/odoo#204527
Original PR description
Steps to reproduce the bug:
- Create a service product “S1”
- Create a repair order:
- In the parts: - Click on the catalog
Problem:
You can select a service product, whereas the products in the repair parts should be restricted to consumable-type products only:
https://github.com/odoo/odoo/blob/f2923dec56b5ba2436bc244337c1e430a85e7e94/addons/stock/models/stock_move.py#L45-L48
opw-4687472
Forward-Port-Of: odoo/odoo#204527Similar to: https://github.com/odoo/odoo/pull/184830 We've recently introduced a new operator: “is within” in the domain selector, which can be used to find out whether a date is within a dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.). To works, this domain needs dynamic elements, such as `context_today`, which is defined in `py_builtin.js` and dynamically retrieves the current date. https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/a
Original PR description
Similar to: https://github.com/odoo/odoo/pull/184830 We've recently introduced a new operator: “is within” in the domain selector, which can be used to find out whether a date is within a dynamic…
Similar to: https://github.com/odoo/odoo/pull/184830
We've recently introduced a new operator: “is within” in the domain
selector, which can be used to find out whether a date is within a
dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.).
To works, this domain needs dynamic elements, such as `context_today`,
which is defined in `py_builtin.js` and dynamically retrieves the
current date.
https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/addons/web/static/src/core/py_js/py_builtin.js#L77-L79
However, the problem isn't limited to this operator in the selector
domain, as it's only been available since 18.0, and this pr target is
17.0.s
In fact, it is possible in certain cases to use these fields via debug
mode, and there are several cases where `uid`, `user`, etc. are used.
There is therefore an inconsistency where users see the use of these
variables in these cases and when they try to use them elsewhere with,
for example, a field of this style:
`("date", "=", context_today())`, they get a traceback.
This happens mainly because, in Python, the domain is evaluated via
`literal_eval`, and since it contains variables that are designed for
the web, it causes a traceback because this function expects to receive
only a correctly formatted string, with no context and no variables.
This commit handles:
- website/model_page.py:
-
https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/addons/website/controllers/model_page.py#L13-L18
https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/addons/website/controllers/model_page.py#L47-L57
The enterprise commit (https://github.com/odoo/enterprise/pull/82564)
handles two other cases:
- web_studio/approval:
Here in this case there are several calls to literal_eval on domains
received from the web, notably to create and check its approval spec.
a function has been used to avoid rewriting the same thing several times
in the file.2
- marketing_automation/activity:
Here too, several calls are made to this file, as in the case of
approval, a function has been created to replace all calls to
`literal_eval`
In all three cases, the problem is the same: the problem is not only
present in `is_within` but in the fact that python has no way of
understanding the domain received from the web, so the same fix has been
applied everywhere:
- First, `to_utc()` is removed from the domain, since it's purely
client-side and this notion doesn't exist in et la the python server
- We replace the `literal_eval` call with `safe_eval`, which will do
more than just transform a string containing only a literal value of
type X into type X (e.g. tuple, string, number, array, etc.)
- `safe_eval` can therefore either evaluate expressions or execute
statements. In our case, what we really want is to evaluate just a
string like literal_eval with just one more context, and to be able to
define local or global values, such as defining `context_today()`
- For the moment, the values we use are the same as those used by
`is_within`, i.e.:
-- context_today()
-- relative_delta()
-- datetime
opw-4551335
opw-4672902
opw-4678894
opw-4669315
opw-4577091
Forward-Port-Of: odoo/odoo#206507
Forward-Port-Of: odoo/odoo#204172When the website domain is defined using punycode (e.g., `xn--ingenieurbro-mlb.localhost`), navigating to the Unicode URL (e.g., `Ingenieurbüro.localhost`) would not reflect the updated `robots.txt`. Steps to reproduce the issue: - Navigate to Website > Configuration > Website. - Set a domain name with punycode (e.g., http://xn--ingenieurbro-mlb.localhost:8069). - Go to settings and modify the robots.txt file. - Visit http://Ingenieurbüro.localhost:8069 and notice that the changes are n
Original PR description
When the website domain is defined using punycode (e.g., `xn--ingenieurbro-mlb.localhost`), navigating to the Unicode URL (e.g., `Ingenieurbüro.localhost`) would not reflect the updated `robots.txt`. Steps to reproduce the issue: - Navigate to Website > Configuration > Website. - Set a domain name with punycode (e.g., http://xn--ingenieurbro-mlb.localhost:8069). - Go to settings and modify the robots.txt file. - Visit http://Ingenieurbüro.localhost:8069 and notice that the changes are not reflected. This commit ensures the correct handling of punycode domains so that the robots.txt is properly served, regardless of whether the domain is accessed in Unicode or punycode form. opw-4641081 Forward-Port-Of: odoo/odoo#206215
The config param skip_create_bank_account_on_reconcile currently also skips the search. In the original commit https://github.com/odoo/odoo/commit/62354663c6622f6d059e36097f0455ab5890b616, it was not the case. It was a mistake during the fw-port 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#
Original PR description
The config param skip_create_bank_account_on_reconcile currently also skips the search. In the original commit https://github.com/odoo/odoo/commit/62354663c6622f6d059e36097f0455ab5890b616, it was not the case. It was a mistake during the fw-port 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#206496 Forward-Port-Of: odoo/odoo#206420
This error occurs when a user attempts to `Configure Document Layout` in settings using a large vertically-oriented image. Steps to Reproduce: - Install the `web` module. - Go to `Settings`. - In the `companies` section, under Your Company, click on `Update Info`. - Upload an image with dimensions width = 8 and height = 901. - Go back, and in the Companies section, click `Configure Document Layout`. ValueError: height and width must be > 0 This error is due to the current lo
Original PR description
This error occurs when a user attempts to `Configure Document Layout` in settings using a large vertically-oriented image. Steps to Reproduce: - Install the `web` module. - Go to `Settings`. - In the…
This error occurs when a user attempts to `Configure Document Layout` in settings using a large vertically-oriented image. Steps to Reproduce: - Install the `web` module. - Go to `Settings`. - In the `companies` section, under Your Company, click on `Update Info`. - Upload an image with dimensions width = 8 and height = 901. - Go back, and in the Companies section, click `Configure Document Layout`. ValueError: height and width must be > 0 This error is due to the current logic in `base_document_layout.py`, where the width (w) is computed using int(50 * base_w / base_h). For highly vertical images (e.g., width = 8, height = 901), this calculation results in w = 0, which subsequently causes a ValueError when passed to the resize() function. This commit resolves the error by using `math.ceil` to compute the width (w) instead of int, ensuring that the value is never zero, even for extremely vertical images. Sentry-6516888945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205017
During this commit: https://github.com/odoo/odoo/commit/2f86fb973a426a4d6c10d41d61dc524955aebb6b we checked the tin1 twice instead of checking the second one task: 4743115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207181
Original PR description
During this commit: https://github.com/odoo/odoo/commit/2f86fb973a426a4d6c10d41d61dc524955aebb6b we checked the tin1 twice instead of checking the second one task: 4743115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207181
Steps to reproduce the issue: - Create a new website using the configurator. - At the step where the color palette is defined, upload a large logo (e.g., 6 MB). - A traceback occurs. The issue comes from the fact that the logo is added to the browser's session storage, which has a 10 MB limit in most modern browsers. Before the logo upload, the session storage already contains some data, and adding a large file goes over the 10 MB limit, which causes the traceback. This commit prevent
Original PR description
Steps to reproduce the issue: - Create a new website using the configurator. - At the step where the color palette is defined, upload a large logo (e.g., 6 MB). - A traceback occurs. The issue comes from the fact that the logo is added to the browser's session storage, which has a 10 MB limit in most modern browsers. Before the logo upload, the session storage already contains some data, and adding a large file goes over the 10 MB limit, which causes the traceback. This commit prevents users from uploading a logo larger than 2.5 MB, which is already a lot for a logo shown in a website header. task-4742810 Forward-Port-Of: odoo/odoo#207071
Two lines in the French Chart of Accounts were inverted. 467 and 468 Steps to reproduce: ------------------- * French Fiscal Localization * Open the Chart of Accounts * Line 467 and 468 > Observation: Why the fix: ------------ Based on french gouvernement documentation https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Plans%20comptables/Plan-de-comptes-PCG-2025.pdf opw-4680252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submi
Original PR description
Two lines in the French Chart of Accounts were inverted. 467 and 468 Steps to reproduce: ------------------- * French Fiscal Localization * Open the Chart of Accounts * Line 467 and 468 > Observation: Why the fix: ------------ Based on french gouvernement documentation https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Plans%20comptables/Plan-de-comptes-PCG-2025.pdf opw-4680252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207216 Forward-Port-Of: odoo/odoo#205323
### Before this commit: The warning message `Invoice will soon be sent to EDI` was not displayed correctly, resulting in a broken UI at the top of the invoice form. - **UI before fix:**  ### After this commit: The warning UI has been fixed by adding appropriate CSS classes, ensuring proper alignment and styling. - **UI after fix:**  ### After this commit: The warning UI has been fixed by adding appropriate CSS classes, ensuring proper alignment and styling. - **UI after fix:**  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206983
Scenario: - edit the website theme and change a font to external font Buda - save and go back to edition and theme tab Result: Infinite spinning when loading the theme tab, and we see an error of AssetsLoadingError as well as an error 400 in console when loading https://fonts.googleapis.com/css?family=Buda URL. Issue: Buda font only has a 300 size, but when loading for the FontFamilyPickerUserValueWidget, we don't specify sizes so google fonts returns an error because there os no 400 size vers
Original PR description
Scenario: - edit the website theme and change a font to external font Buda - save and go back to edition and theme tab Result: Infinite spinning when loading the theme tab, and we see an error of AssetsLoadingError as well as an error 400 in console when loading https://fonts.googleapis.com/css?family=Buda URL. Issue: Buda font only has a 300 size, but when loading for the FontFamilyPickerUserValueWidget, we don't specify sizes so google fonts returns an error because there os no 400 size version of the font. This is not an issue when adding the font because we use 300 up to 700: d0ba6c26e64e711e21b191bdba0ede14abc6afb9 This is also not an issue for self-hosted google font because we load it with the same parameters: 5145d84dc02d8068a5feaac769f5d83cefc65804 opw-4657897 opw-4497707 opw-4338034 opw-3236787 opw-3584322 opw-3306789 Forward-Port-Of: odoo/odoo#207229
These tests create sale orders, but `self.env.user` does not necessarily have the right to create one by default. https://runbot.odoo.com/odoo/error/163635 Forward-Port-Of: odoo/enterprise#83672
Original PR description
These tests create sale orders, but `self.env.user` does not necessarily have the right to create one by default. https://runbot.odoo.com/odoo/error/163635 Forward-Port-Of: odoo/enterprise#83672
### Issue: Although Fedex's API shoud accept GBP's UK currency for rate requests, you will raise a `CURRENCY.TYPE.INVALID` error from Fedex if you try to get the shipping rate for an order whose currency is GBP. ### Steps to reproduce: - Install UK accounting and select UK's company: the currency will be GBP - Install and set up Fedex Integration - Configure the Fedex in the delivery method, FEDEX_YOU_PACKAGE and Fedex priority for package type and service type - Create a sale order,
Original PR description
### Issue: Although Fedex's API shoud accept GBP's UK currency for rate requests, you will raise a `CURRENCY.TYPE.INVALID` error from Fedex if you try to get the shipping rate for an order whose…
### Issue: Although Fedex's API shoud accept GBP's UK currency for rate requests, you will raise a `CURRENCY.TYPE.INVALID` error from Fedex if you try to get the shipping rate for an order whose currency is GBP. ### Steps to reproduce: - Install UK accounting and select UK's company: the currency will be GBP - Install and set up Fedex Integration - Configure the Fedex in the delivery method, FEDEX_YOU_PACKAGE and Fedex priority for package type and service type - Create a sale order, add shipping and get the shipping rate for your set up fedex UK. #### > Fedex request error: `CURRENCY.TYPE.INVALID` ### Cause of the issue: The currency used in the fedex request is the currency of the order: https://github.com/odoo/enterprise/blob/07845988daad911b10de3b7199b81cc4ed3cfba9/delivery_fedex_rest/models/delivery_fedex.py#L133-L141 that is GBP, however since 44e32359bb79eed08a41861e155c98f664c6d09a we do not automatically convert the GBP currency in UKL. Since Fedex API does not seem to support the GBP we raise the error. ### Fix: We should use the currency conversion available between GBP and UKL. opw-4712354 Forward-Port-Of: odoo/enterprise#83388
Similar to: https://github.com/odoo/odoo/pull/184830 We've recently introduced a new operator: “is within” in the domain selector, which can be used to find out whether a date is within a dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.). To works, this domain needs dynamic elements, such as `context_today`, which is defined in `py_builtin.js` and dynamically retrieves the current date. https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/core/py_js/py
Original PR description
Similar to: https://github.com/odoo/odoo/pull/184830 We've recently introduced a new operator: “is within” in the domain selector, which can be used to find out whether a date is within a dynamic…
Similar to: https://github.com/odoo/odoo/pull/184830
We've recently introduced a new operator: “is within” in the domain
selector, which can be used to find out whether a date is within a
dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.).
To works, this domain needs dynamic elements, such as `context_today`,
which is defined in `py_builtin.js` and dynamically retrieves the
current date.
https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/core/py_js/py_builtin.js#L77-L79
However, the problem isn't limited to this operator in the selector
domain, as it's only been available since 18.0, and this pr target is
17.0.s
In fact, it is possible in certain cases to use these fields via debug
mode, and there are several cases where `uid`, `user`, etc. are used.
There is therefore an inconsistency where users see the use of these
variables in these cases and when they try to use them elsewhere with,
for example, a field of this style:
`("date", "=", context_today())`, they get a traceback.
This happens mainly because, in Python, the domain is evaluated via
`literal_eval`, and since it contains variables that are designed for
the web, it causes a traceback because this function expects to receive
only a correctly formatted string, with no context and no variables.
The community commit (https://github.com/odoo/odoo/pull/204172) handles:
- website/model_page.py:
https://github.com/odoo/odoo/blob/17.0/addons/website/controllers/model_page.py#L13-L18
https://github.com/odoo/odoo/blob/17.0/addons/website/controllers/model_page.py#L47-L50
This commit
handles two other cases:
- web_studio/approval:
Here in this case there are several calls to literal_eval on domains
received from the web, notably to create and check its approval spec.
a function has been used to avoid rewriting the same thing several times
in the file.2
- marketing_automation/activity:
Here too, several calls are made to this file, as in the case of
approval, a function has been created to replace all calls to
`literal_eval`
In all three cases, the problem is the same: the problem is not only
present in `is_within` but in the fact that python has no way of
understanding the domain received from the web, so the same fix has been
applied everywhere:
- First, `to_utc()` is removed from the domain, since it's purely
client-side and this notion doesn't exist in the python server
- We replace the `literal_eval` call with `safe_eval`, which will do
more than just transform a string containing only a literal value of
type X into type X (e.g. tuple, string, number, array, etc.)
- `safe_eval` can therefore either evaluate expressions or execute
statements. In our case, what we really want is to evaluate just a
string like literal_eval with just one more context, and to be able to
define local or global values, such as defining `context_today()`
- For the moment, the values we use are the same as those used by
`is_within`, i.e.:
- context_today()
- relative_delta()
- datetime
- time
opw-4551335
opw-4672902
opw-4678894
opw-4669315
opw-4577091
community: https://github.com/odoo/odoo/pull/204172
Forward-Port-Of: odoo/enterprise#83635
Forward-Port-Of: odoo/enterprise#82564Forward-Port-Of: odoo/enterprise#83992
Original PR description
Forward-Port-Of: odoo/enterprise#83992