[FW][FIX] web: list: tolerate editable"1" (only in stable) #162906
Closed
Conversation
This file contains 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
A few x2many list embedded in form views have the "editable" attr set to "1". Normally, the valid values for this attribute are "top" and "bottom". Regular list views are validated, but not lists inside form views. When set to "1", some features of the model aren't enabled. For instance, when the current page is full and the user adds a record, the limit isn't temporarilly increased for the added record to be displayed on the current page, like it would be in editable="bottom" lists, so the user doesn't see the record he just added. The issue can be observed in the stock move form view for instance. This commit is only good for stable versions: we add a fallback on "bottom" s.t. if the editable attribute is set, it's always either "top" or "bottom". In master, we'll probably rethink the API. opw~3860903 X-original-commit: bfffd2e
|
|
|
This PR targets saas-17.1 and is part of the forward-port chain. Further PRs will be created up to master. More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port |
robodoo
pushed a commit
that referenced
this pull request
Apr 23, 2024
A few x2many list embedded in form views have the "editable" attr set to "1". Normally, the valid values for this attribute are "top" and "bottom". Regular list views are validated, but not lists inside form views. When set to "1", some features of the model aren't enabled. For instance, when the current page is full and the user adds a record, the limit isn't temporarilly increased for the added record to be displayed on the current page, like it would be in editable="bottom" lists, so the user doesn't see the record he just added. The issue can be observed in the stock move form view for instance. This commit is only good for stable versions: we add a fallback on "bottom" s.t. if the editable attribute is set, it's always either "top" or "bottom". In master, we'll probably rethink the API. opw~3860903 closes #162906 X-original-commit: bfffd2e Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com> Signed-off-by: Aaron Bohy (aab) <aab@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.
A few x2many list embedded in form views have the "editable" attr set to "1". Normally, the valid values for this attribute are "top" and "bottom". Regular list views are validated, but not list inside form views.
When set to "1", some features of the model aren't enabled. For instance, when the current page is full and the user adds a record, the limit isn't temporarilly increased for the added to be dusplayed on the current page, like it would be in editable="bottom" lists, so the user doesn't see the record he just added.
The issue can be observed in the stock move form view for instance.
This commit is only good for stable versions: we add a fallback on "bottom" s.t. if the editable attribute is set, it's always either "top" or "bottom".
In master, we'll probably rethink the API.
opw~3860903
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: #162832