IDEMPIERE-5169 OAuth2: add same email account on other client will break it on old client

[CarlosRuiz-globalqss]

https://idempiere.atlassian.net/browse/IDEMPIERE-5169

Opening this in draft because is not tested against real potential cases:

• column AD_AuthorizationAccount.AccessToken encrypted and unencrypted
• multitenant
• potentially different encryption keys in different tenants

[hieplq]

after fix review comment then i test success but not-success with encrypt case by issue report at IDEMPIERE-5168

1. i get bellow exception when run encrypt process because i have accessKey when encrypt make length > 8000 character
   23:59:37.207===========> ColumnEncryption.changeFieldLength: EncryptError [ChangeFieldLength]: ColumnID=214402, NewLength=8016 [274] 23:59:37.218===========> ColumnEncryption.process: java.lang.Exception [274] java.lang.Exception at org.compiere.process.ColumnEncryption.changeFieldLength(ColumnEncryption.java:519)

2. i change data type of accessKey to textLong by that i can't run encrypt process by readonly logic

[CarlosRuiz-globalqss]

2. i change data type of accessKey to textLong by that i can't run encrypt process by readonly logic

I haven't tested, if CLOB columns can be encrypted by iDempiere, we can add that one to the readonly logic.

[hieplq]

if CLOB columns can be encrypted by iDempiere

i saw binary and text long on list readonly. by that logic i think image type also need to add to list
but how to resolve IDEMPIERE-5168?

[CarlosRuiz-globalqss]

if CLOB columns can be encrypted by iDempiere

i saw binary and text long on list readonly. by that logic i think image type also need to add to list but how to resolve IDEMPIERE-5168?

I mean, if you can test removing the "Text" reference ID from the read-only logic and test if iDempiere is capable of encrypting/decrypting correctly a CLOB value, I don't see clearly a reason why iDempiere would not be able to do it

[hieplq]

test passed for whole case with support of IDEMPIERE-5168