can delete org, account record in "Account Schema Dimensions"

Description

In Accounting Schema > Account Schema Dimensions
normal by below ticket, we can't delete, change record has type is account, org
http://ehc.ac/p/adempiere/mailman/adempiere-trackers/thread/E1IWwwg-0007kX-C5%40sc8-sf-web21.sourceforge.net/#msg10909186

but I can with below testcase:
1. change type from account to "Sub Account", save record
2. delete record success.

Hi Carlos, you can write down logic of constrain in before save and before delete. I can recode, and test it.

Environment

None

Activity

Show:
Carlos Ruiz
March 23, 2014, 4:53 PM

Good catch

Anton Mostovenko
May 9, 2020, 11:42 AM

Reproduced by Anton Mostovenko

Edwin Ang
June 25, 2020, 10:16 AM

Reproduced too. Accounting dimension is one of the most critical setup. I don’t think the record should be deleteable. Should implement both Application Dictionary validation and beforeDelete prevention.

are you interested in working on it?

Carlos Ruiz
June 26, 2020, 9:18 PM

A very simple patch is to make the account type not updatable.

Carlos Ruiz
July 20, 2020, 8:05 PM

https://github.com/idempiere/idempiere/pull/150

wrote:

Hi @globalqss, I think that shouldn't apply to new C_AcctSchema_Element record.

Hi , after analyzing this further and doing some tests, I think this validation (forbidding deleting or inactivating these records).
This was added on this commit:
https://github.com/idempiere/idempiere/commit/be8de78
following this ticket:
https://sourceforge.net/p/adempiere/bugs/773/

The logic followed on that ticket is missing the fact that you can have multiple elements for the "Account" type, with different "Account Element" - this is a common case for example to add other trees, not just accounts.

So, my test case went like the following:

  • I added a second record for organization (which is wrong), but after that I cannot delete it and also I cannot inactivate it.

  • samely I added a second record for account - suppose a user does the same and then notice it was a mistake, then the user cannot change the type, cannot inactivate it and cannot delete it - it will be forced to use SQL (which is very bad IMHO)

So, taking into account that if a user mistakenly deletes or inactivate such element - the solution is very simple, is just to add it back - I think is better to drop that validation.

I made a second commit in the pull request reverting that part for the original commit.

Regards,

Carlos Ruiz

Assignee

Carlos Ruiz

Reporter

Hiep Lq

Tested By

None

Components

Affects versions

Priority

Minor
Configure