Integrity Errors should appear as user-friendly!

Bug #431247 reported by forstera
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Odoo Server (MOVED TO GITHUB)
Fix Released
Medium
Ravi Gadhia (OpenERP)

Bug Description

Hello,

When I delete a partner, the corresponding line in res_partner_address is not deleted or at least the value in the field partner_id. then, If I've some contacts that were affilied to the same address, the fact to display them causes a crash :

Environment Information :
System : Windows-32bit-SP1
OS Name : nt
Operating System Release :
Operating System Version : 32bit
Operating System Architecture : 32bit
Operating System Locale : fr_CH.cp1252
Python Version : 2.5.2
OpenERP-Client Version : 5.0.3
Last revision No. & ID :Bazaar Package not Found !Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/openerp-server-5.0.3.1/bin/netsvc.py", line 244, in dispatch
    result = LocalService(service_name)(method, *params)
  File "/usr/lib/python2.5/site-packages/openerp-server-5.0.3.1/bin/netsvc.py", line 73, in __call__
    return getattr(self, method)(*params)
  File "/usr/lib/python2.5/site-packages/openerp-server-5.0.3.1/bin/service/web_services.py", line 583, in execute
    res = service.execute(db, uid, object, method, *args)
  File "/usr/lib/python2.5/site-packages/openerp-server-5.0.3.1/bin/osv/osv.py", line 59, in wrapper
    return f(self, dbname, *args, **kwargs)
  File "/usr/lib/python2.5/site-packages/openerp-server-5.0.3.1/bin/osv/osv.py", line 118, in execute
    res = pool.execute_cr(cr, uid, obj, method, *args, **kw)
  File "/usr/lib/python2.5/site-packages/openerp-server-5.0.3.1/bin/osv/osv.py", line 110, in execute_cr
    return getattr(object, method)(cr, uid, *args, **kw)
  File "/usr/lib/python2.5/site-packages/openerp-server-5.0.3.1/bin/osv/orm.py", line 2080, in read
    result = self._read_flat(cr, user, select, fields, context, load)
  File "/usr/lib/python2.5/site-packages/openerp-server-5.0.3.1/bin/osv/orm.py", line 2191, in _read_flat
    res2 = self._columns[f].get(cr, self, ids, f, user, context=context, values=res)
  File "/usr/lib/python2.5/site-packages/openerp-server-5.0.3.1/bin/osv/fields.py", line 640, in get
    res = self._fnct(obj, cr, user, ids, name, self._arg, context)
  File "/usr/lib/python2.5/site-packages/openerp-server-5.0.3.1/bin/osv/fields.py", line 759, in _fnct_read
    return res
KeyError: 7610

the KeyErrro value is the id of the partner that was deleted.

Now, In the same way. If I try to delete a partner that has an invoice in account_invoice, I get the following warning :
null value in column "partner_id" violates not-null constraint
CONTEXT: SQL statement "UPDATE ONLY "public"."account_invoice" SET "partner_id" = NULL WHERE $1 OPERATOR(pg_catalog.=) "partner_id""

For end users, wouldn't it be better to have a message like ' Deleting not possible, corresponding recors in the accounting ...' ?

thanks

Revision history for this message
Mantavya Gajjar (Open ERP) (mga) wrote :

Need to implement a message system like warning module

Changed in openobject-server:
importance: Undecided → Wishlist
Revision history for this message
Jan Verlaan (jan-verlaan) wrote :

Are you sure this is a wishlist depended on a message system?
A "fatal error" may never occur, should be the base rule I hope, and needs to be prevented to catch the error and give a nice message.
At least a check can be done in the delete action if there exists a relation and if yes, give a message about the related record.
This way user can manually delete the related record with the given hint and can then try to delete the partner record again.
Hope this bug status will be reverted.

Revision history for this message
forstera (arnaud-forster-deactivatedaccount) wrote :

I agree with Jan Verlaan; for 'standard' users, having such a message is incomprehensible.

In another way, there's still the bug that when we delete a parner, we keep its id numbe in the res_partner_address table. The problem is even more deeper than that :

A contact has a job in a company. We have then the following relation :

res_partner_contact <---> res_partner_job <---> res_partner_address <----> res_partner

We agree that if I delete a partner, the job of my contact at this partner doesnt exist anymore. So, when I delete a partner, all records according to my partner is res_partner_addres and all records linked to res_partner_address in res_partner_job should be deleted, too.

Revision history for this message
Mantavya Gajjar (Open ERP) (mga) wrote :

Hello Jan Verlaan,

I am talking about a system where these all http://www.postgresql.org/docs/8.1/static/errcodes-appendix.html Errors / Exceptions will be taken care and again it will be customisable depending on user / language.

as currently in the system the raw message taken from the postgres->psycopg2->openerp and display the same on the message, i agree it should not like that.

and for the request of forstera,
"""In another way, there's still the bug that when we delete a parner, we keep its id numbe in the res_partner_address table. The problem is even more deeper than that :""" - I an not agree with this as because if you delete the partner in address this will be set to null bcoz of "res_partner_address_partner_id_fkey" FOREIGN KEY (partner_id) REFERENCES res_partner(id) ON DELETE SET NULL, this is already defined on the address table.

According to me,
Its better to keep that record inactive rather then deleting that record. may help in the future for the reference, just put boolean field with name `active` on any object and it will provide facility to make record active, inactive as and when required.

Revision history for this message
Mantavya Gajjar (Open ERP) (mga) wrote :

Hell !!!

here i have placed the blueprints for better error message handling.
https://blueprints.launchpad.net/openobject-server/+spec/custome-error-message

Revision history for this message
forstera (arnaud-forster-deactivatedaccount) wrote :

Hello mga,

I did not understdood your last post when you talekd about res_partner_address.. I agree with you when you say is't better not to delete thre record but make it inactive. But in another way, there's still a problem if we delete a partner. I checked in my table res_partner_address and the field partner_id has the property 'n'o. The problem when I delete a partner is the following. If I have a contact that has a job to the deleted partner, the job is still there. So, when I open my partner, ERP says : yes your contact has a job as <whatever you want> in a company but I can't find this company. But email address for this job, address and phone number are there. But these informations are not available anymore because the partner doesnt exists anymore ...

Revision history for this message
Mantavya Gajjar (Open ERP) (mga) wrote :

No need to delete address, as not partner is not compulsory field in address, even address can be stand alone without partner

Changed in openobject-server:
status: New → Invalid
Revision history for this message
Jan Verlaan (jan-verlaan) wrote :

What about the fatal error mentioned into the original bugtracker? Is it still there?
If yes then
. this bugtracker can not be "Invalid"
. put back in other state OR link to other bug

Thanks

Revision history for this message
Cristian Salamea (ovnicraft) wrote :

First of all, here there are 2 things:
1. the problem deleting partners and their contacts (res.partner.address)
2. content of messages when user try to break integrity

i think we must talk about one think related with description in the bug, @forstera the message what you received (deleting a partner with invoice) is not in the same way with the error.

So can you describe the process to reach the error, i deleted severals partners with contacts but i cant reproduce the error.

Cristian,

Revision history for this message
Jay Vora (Serpent Consulting Services) (jayvora) wrote :

I stand to 3 points:
1. Deleting Partner should NOT delete address. As it has been said earlier, Address can be an independent identity rather than linked to any partner.
2. Integrity errors should be turned into user friendly messages where non-technical persons can understand the scenario why it is an error.
3. There should not happen any errors such as keyerrors.

We are considering these issues and will come out with a solution.

Thank you for your interest.

Changed in openobject-server:
status: Invalid → Confirmed
Changed in openobject-server:
status: Confirmed → Invalid
Changed in openobject-server:
status: Invalid → Confirmed
Revision history for this message
Richard (John) Nopkins@Servosoft (richard-nopkins) wrote :

Hello folks,

our team is also facing problems with integiry not null stufffs.

i agree to cristian,jan and jay(openerp).

there has to b sum way 2 have this issue resolved.

can i reopen this one? community should work to enhance rather than hiding problems.

allow me to reopen my GODS :)

Revision history for this message
Richard (John) Nopkins@Servosoft (richard-nopkins) wrote :

oops, someone just did it:(

Revision history for this message
Mantavya Gajjar (Open ERP) (mga) wrote :

hello jay,

can you check and confirm please ?

Changed in openobject-server:
assignee: nobody → Jay (Open ERP) (jvo-openerp)
Revision history for this message
forstera (arnaud-forster-deactivatedaccount) wrote :

Hello all,

Any news about it ? There are now 10 months that this is open .....

Thanks

summary: - Deleting a partner doesnt delete the corresponding line in
- res_partner_address
+ Integrity Errors should appear as user-friendly!
Changed in openobject-server:
milestone: none → 6.0
assignee: Jay (Open ERP) (jvo-openerp) → RGA(Open ERP) (rga-openerp)
Revision history for this message
Jay Vora (Serpent Consulting Services) (jayvora) wrote :

Thanks RGA and ODO.

Changed in openobject-server:
status: Confirmed → Fix Released
importance: Wishlist → Medium
Revision history for this message
ciprian (ciprian-parfon) wrote :

Hi gents,

Has this been resolved? I have the same issue. I can see on status that there is a "Fix Released". Where is this fix? How do I apply it ?
Please help.

Thanks.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.