[FIX] models.py: Raise user friendly error message on sql constraints #36458
Conversation
tivisse
force-pushed
the
saas-12.5-fixes-yti
branch
3 times, most recently
from
96c65f5
to
39d47d4
Compare
robodoo
added
CI 🤖
tivisse
force-pushed
the
saas-12.5-fixes-yti
branch
from
52b50a0
to
158a7b0
Compare
|
@robodoo r+ |
|
@robodoo rebase-ff |
|
Merge method set to rebase and fast-forward |
|
'ci/runbot' failed on this reviewed PR. |
2 similar comments
|
'ci/runbot' failed on this reviewed PR. |
|
'ci/runbot' failed on this reviewed PR. |
tivisse
force-pushed
the
saas-12.5-fixes-yti
branch
from
158a7b0
to
80b46d7
Compare
tivisse
force-pushed
the
saas-12.5-fixes-yti
branch
from
80b46d7
to
9a0f650
Compare
|
@robodoo r+ |
| @@ -357,6 +357,7 @@ def create(self, vals_list): | |||
| templates._create_variant_ids() | |||
|
|
|||
| # This is needed to set given values to first variant after creation | |||
| self.flush() | |||
There was a problem hiding this comment.
We wonder what's the use of this. Could you specify? Maybe with a comment?
There was a problem hiding this comment.
To avoid a cache miss. When trying to update the variant values according to the template values, the newly created records should be flushed.
Don't you think that the commit message is not sufficient ? :)
In fact, maybe we could add to the guidelines the fact that all the calls to flush should be documented in that case.
What do you think ?
There was a problem hiding this comment.
Well, even with this comment I still don't get it.
the newly created records should be flushed.
creates are not delayed. So if you need a a template id for your variants, it will be there.
Unless you require a specific stored field for the template that has just been created, this call to flush shouldnt be needed. And if this is the case, then should precise the field in the call to flush so this is explicit. For instance
self.flush(['amount_total'])
What is the use case leading to the issue/traceback?
There was a problem hiding this comment.
Hi.
After a small investigation, it seems you're right ! ;)
This commit bb505de fix both issues.
Thanks.
robodoo
added
error 🙅
and removed
CI 🤖
|
Staging failed: ci/runbot on 56be306196ee4ba3dfd1a1765f193a954c4e5ce0 (view more at http://runbot.odoo.com/runbot/build/614541) |
|
Staging failed: ci/runbot on bbadab5dce0f014e229c18048a5c39bd5c6fb458 (view more at http://runbot.odoo.com/runbot/build/615179) |
Purpose ======= When you edit a Time Off Request from the dashboard. The title in the header is undefined https://drive.google.com/open?id=1vBg9AlVCN7rc5D6DUel8hx2uY-oOfwRs
Purpose ======= Have the same mechanism for time off responsibles between leaves and allocations.
When writing on date_from or date_to, request_date_from and request_date_to should also change
In the case of allocations, it should simply be possible to copy them In the case of leave requests, we want to have a "beautiful" message for the user in case he cannot duplicate the leave request (overlapping leave requests) But it makes no sense to not allow at copying it in case the date_from and date_to are actually provided
Purpose ======= On a record creation, a valid and user friendly error message is raised when a sql constraint is violated. (Eg: 'The start date must be anterior to the end date'). On a record modification, this is not always the case anymore, since the latest ORM modifications. Eg: Write on a leave with a date_from > date_to, you got the postgreSQL error, which is not understable by a classic human. This is due to the fact that the error is correctly catched and logged, but the result is set into the cache, triggering the execution of computation methods, and calling _validate_fields. It is highly probable that a flush is done in the constraint method (search, read, ...). In that case the postgreSQL error is converted into a ValidationError, with a stringified version of the IntegrityError, and thus is not catched by the check wrapper.
tivisse
force-pushed
the
saas-12.5-fixes-yti
branch
from
9a0f650
to
bb505de
Compare
Purpose ======= When trying the translate a sql_contraint message after an integrity error we use the current cursor in a 'with', just to make a SELECT query. That way, the cursor is commited at the end of the with statement, trying to commit the inconsitent state of the cursor that was the reason of the integrity error. Just close the cursor, as we only fetch translations from the database.
tivisse
force-pushed
the
saas-12.5-fixes-yti
branch
from
bb505de
to
a904fe1
Compare
|
@robodoo r+ rebase-ff |
|
Merge method set to rebase and fast-forward |
|
Linked pull request(s) odoo/enterprise#5521 not ready. Linked PRs are not staged until all of them are ready. |
Purpose ======= When trying the translate a sql_contraint message after an integrity error we use the current cursor in a 'with', just to make a SELECT query. That way, the cursor is commited at the end of the with statement, trying to commit the inconsitent state of the cursor that was the reason of the integrity error. Just close the cursor, as we only fetch translations from the database. closes #36458 Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
Merged at 1a0a437, thanks! |
Purpose
On a record creation, a valid and user friendly error message is raised
when a sql constraint is violated. (Eg: 'The start date must be anterior
to the end date').
On a record modification, this is not always the case anymore, since the
latest ORM modifications.
Eg: Write on a leave with a date_from > date_to, you got the postgreSQL
error, which is not understable by a classic human.
This is due to the fact that the error is correctly catched and logged,
but the result is set into the cache, triggering the execution of computation
methods, and calling _validate_fields. It is highly probable that a flush
is done in the constraint method (search, read, ...). In that case the
postgreSQL error is converted into a ValidationError, with a stringified
version of the IntegrityError, and thus is not catched by the check wrapper.
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