chore: Remove confidential values [DHIS2-21518]#23937
Conversation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
ameenhere
left a comment
ameenhere
left a comment
There was a problem hiding this comment.
Can you confirm that the encryption system config was only exclusively used by Tracker for TEAV confidential feature?
|
EncryptionStatus was used to determine if dhis.conf has a encryption key or not if I recall, which also relates to DhisConfigurationProvider getEncryptionStatus and checkSecurityConfiguration and SystemInfo.encryption. All of these were in place to know whether we could or could not encrypt. In addition to confidential attributes, the same kind of encryption is used for settings (passwords, etc.). I'm not sure if it's used by the AES-128 encryption we use for RouteService and EventHookSecretManager, but I think in either case that part of the code should not be removed :) |
|
Just for reference and to add to Stian's comment about which features use the encryption feature, the datastore and user datastore both use it. |
| .collect(Collectors.toList()); | ||
| } | ||
|
|
||
| private boolean isNotConfidential(TrackedEntityAttribute trackedEntityAttribute) { |
There was a problem hiding this comment.
Do we need a similar primitive safe method? How would the getSkipAnalytics behave if it happened to be null?
|
5 participants
Summary
Removes the confidential/encryption feature from
TrackedEntityAttributeandTrackedEntityAttributeValue.Adding @dhis2/analytics-backend since this PR touches files under
dhis-service-analytics.Changes
confidentialfield.plainValue/encryptedValuestaging design with a single plain value field.E1112validation.Migration
The migration script:
confidentialfield fromtrackedentityattribute.skipanalytics = truefor attributes whereconfidential = true.trackedentityattributevaluewhen a plain value is also present.