Consider the following code:
==
person = delegator.makeValue("Person", UtilMisc.toMap("partyId", "1234");
person.setString("socialSecurityNumber", "1234");
person.store();
assertEquals("1234", person.get("socialSecurityNumber"));
==
The assert will *fail*, because when the store() is called, the
encrypted value is stored into the entity. Then, when it is fetched for
the assert, it is not decrypted.
The problem with the workflow here, is that the delegator updates the
fields with encrypt=true temporarily while storing the data to the
database; this then leaves the entity in an unknown state. Calling code
probably expects the encrypted fields to retain their set values.
This same bug will break the TestRollback feature(it saved the value
after the fields have been encrypted), the audit log feature(for the
same reason), the eca rules that run at the end of delegator call, etc.
However, even that is kinda odd. If the entity definition has lock
enabled, then an implicit refresh() is called on it, which will 'fix'
this problem.
ps: Has anyone else noticed that running *just* the entity engine test
suite, with cobertura enabled, doesn't give any coverage on
framework/entity, instead only showing coverage on framework/base?
