[FW][FIX] *: domain field: option allow_expressions #210145
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
|
@Polymorphe57 @aab-odoo cherrypicking of pull request #208876 failed. stdout: Either perform the forward-port manually (and push to this branch, proceeding as usual) or close this PR (maybe?). In the former case, you may want to edit this PR message as well. More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port |
841b92f to
ab457af
Compare
ab457af to
678a0fa
Compare
Some views use a domain widget to edit/save a domain and use it afterwards in several places where domains must have literals only. Typically, a literal_eval is used to evaluate the (string) domain. Thus expressions like "uid" or "context_today()"" should not be used in those contexts. Here we introduce an option "allow_expressions" (default False) for the domain field and use it to mark as invalid domains that contain expressions when the option is set to False. A notification is displayed when a domain contains an unwanted expressions. Since we cannot expect modules like base to be updated, we have to find another system to allow the usage of expressions in the form views for the models ir.filters and base.automation: we simply hardcode those models as allowing expressions. Since for these models, the evaluation of domains is done via safe_eval but with a restricted evaluation context, we also display a notification that alerts the user that the evaluation of expressions (although accepted by the domain field) can fail. We revert the recent commit odoo@f95c494 that introduced potentially problematic calls to safe_eval in order to allow evaluation of expressions. Forward-port-of: odoo#208876 X-original-commit: 329867a
6fc45ae to
a036f18
Compare
The domain field passes a new prop allowExpressions to the domain selector. If that prop is false (default true), the within operator is not proposed for selection for date/datetime fields. This is done to prevent users to introduce expressions in their domains when they are not supported.
a036f18 to
e287f35
Compare
|
@robodoo r+ |
|
@Polymorphe57 @aab-odoo because this PR has multiple commits, I need to know how to merge it:
|
|
robodoo rebase-ff |
|
Merge method set to rebase and fast-forward. |
robodoo
pushed a commit
that referenced
this pull request
May 17, 2025
Some views use a domain widget to edit/save a domain and use it afterwards in several places where domains must have literals only. Typically, a literal_eval is used to evaluate the (string) domain. Thus expressions like "uid" or "context_today()"" should not be used in those contexts. Here we introduce an option "allow_expressions" (default False) for the domain field and use it to mark as invalid domains that contain expressions when the option is set to False. A notification is displayed when a domain contains an unwanted expressions. Since we cannot expect modules like base to be updated, we have to find another system to allow the usage of expressions in the form views for the models ir.filters and base.automation: we simply hardcode those models as allowing expressions. Since for these models, the evaluation of domains is done via safe_eval but with a restricted evaluation context, we also display a notification that alerts the user that the evaluation of expressions (although accepted by the domain field) can fail. We revert the recent commit f95c494 that introduced potentially problematic calls to safe_eval in order to allow evaluation of expressions. Forward-port-of: #208876 X-original-commit: 329867a Part-of: #210145 Related: odoo/enterprise#85620 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com> Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
acsonefho
pushed a commit
to acsone/odoo
that referenced
this pull request
May 19, 2025
Some views use a domain widget to edit/save a domain and use it afterwards in several places where domains must have literals only. Typically, a literal_eval is used to evaluate the (string) domain. Thus expressions like "uid" or "context_today()"" should not be used in those contexts. Here we introduce an option "allow_expressions" (default False) for the domain field and use it to mark as invalid domains that contain expressions when the option is set to False. A notification is displayed when a domain contains an unwanted expressions. Since we cannot expect modules like base to be updated, we have to find another system to allow the usage of expressions in the form views for the models ir.filters and base.automation: we simply hardcode those models as allowing expressions. Since for these models, the evaluation of domains is done via safe_eval but with a restricted evaluation context, we also display a notification that alerts the user that the evaluation of expressions (although accepted by the domain field) can fail. We revert the recent commit odoo@f95c494 that introduced potentially problematic calls to safe_eval in order to allow evaluation of expressions. Forward-port-of: odoo#208876 X-original-commit: 329867a Part-of: odoo#210145 Related: odoo/enterprise#85620 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com> Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
acsonefho
pushed a commit
to acsone/odoo
that referenced
this pull request
May 19, 2025
The domain field passes a new prop allowExpressions to the domain selector. If that prop is false (default true), the within operator is not proposed for selection for date/datetime fields. This is done to prevent users to introduce expressions in their domains when they are not supported. closes odoo#210145 Related: odoo/enterprise#85620 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com> Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
ThomasSchneider-94
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Jun 4, 2025
Some views use a domain widget to edit/save a domain and use it afterwards in several places where domains must have literals only. Typically, a literal_eval is used to evaluate the (string) domain. Thus expressions like "uid" or "context_today()"" should not be used in those contexts. Here we introduce an option "allow_expressions" (default False) for the domain field and use it to mark as invalid domains that contain expressions when the option is set to False. A notification is displayed when a domain contains an unwanted expressions. Since we cannot expect modules like base to be updated, we have to find another system to allow the usage of expressions in the form views for the models ir.filters and base.automation: we simply hardcode those models as allowing expressions. Since for these models, the evaluation of domains is done via safe_eval but with a restricted evaluation context, we also display a notification that alerts the user that the evaluation of expressions (although accepted by the domain field) can fail. We revert the recent commit odoo@f95c494 that introduced potentially problematic calls to safe_eval in order to allow evaluation of expressions. Forward-port-of: odoo#208876 X-original-commit: 329867a Part-of: odoo#210145 Related: odoo/enterprise#85620 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com> Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
ThomasSchneider-94
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Jun 4, 2025
The domain field passes a new prop allowExpressions to the domain selector. If that prop is false (default true), the within operator is not proposed for selection for date/datetime fields. This is done to prevent users to introduce expressions in their domains when they are not supported. closes odoo#210145 Related: odoo/enterprise#85620 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com> Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
gamarino
pushed a commit
to numaes/numa-public-odoo
that referenced
this pull request
Jun 4, 2025
Some views use a domain widget to edit/save a domain and use it afterwards in several places where domains must have literals only. Typically, a literal_eval is used to evaluate the (string) domain. Thus expressions like "uid" or "context_today()"" should not be used in those contexts. Here we introduce an option "allow_expressions" (default False) for the domain field and use it to mark as invalid domains that contain expressions when the option is set to False. A notification is displayed when a domain contains an unwanted expressions. Since we cannot expect modules like base to be updated, we have to find another system to allow the usage of expressions in the form views for the models ir.filters and base.automation: we simply hardcode those models as allowing expressions. Since for these models, the evaluation of domains is done via safe_eval but with a restricted evaluation context, we also display a notification that alerts the user that the evaluation of expressions (although accepted by the domain field) can fail. We revert the recent commit odoo/odoo@f95c494 that introduced potentially problematic calls to safe_eval in order to allow evaluation of expressions. Forward-port-of: #208876 X-original-commit: 329867ade9a6767388511b81fd0cb298a720657e Part-of: odoo/odoo#210145 Related: odoo/enterprise#85620 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com> Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
gamarino
pushed a commit
to numaes/numa-public-odoo
that referenced
this pull request
Jun 4, 2025
The domain field passes a new prop allowExpressions to the domain selector. If that prop is false (default true), the within operator is not proposed for selection for date/datetime fields. This is done to prevent users to introduce expressions in their domains when they are not supported. closes odoo/odoo#210145 Related: odoo/enterprise#85620 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com> Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some views use a domain widget to edit/save a domain and use it afterwards in several places where domains must have literals only. Typically, a literal_eval is used to evaluate the (string) domain. Thus expressions like "uid" or "context_today()"" should not be used in those contexts.
Here we introduce an option "allow_expressions" (default False) for the domain field and use it to mark as invalid domains that contain expressions when the option is set to False. A notification is displayed when a domain contains an unwanted expressions.
Since we cannot expect modules like base to be updated, we have to find another system to allow the usage of expressions in the form views for the models ir.filters and base.automation: we simply hardcode those models as allowing expressions. Since for these models, the evaluation of domains is done via safe_eval but with a restricted evaluation context, we also display a notification that alerts the user that the evaluation of expressions (although accepted by the domain field) can fail.
We revert the recent commit a678755 that introduced potentially problematic calls to safe_eval in order to allow evaluation of expressions.
Forward-Port-Of: #209960
Forward-Port-Of: #208876
Another fix is added here:
The domain field passes a new prop allowExpressions to the domain selector. If that prop is false (default true), the within operator is not proposed for selection for date/datetime fields. This is done to prevent users to introduce expressions in their domains when they are not supported.