Feature proposal #7164
closed
Implement additional column for terms and conditions fields to log consent
Description
This should keep track of the exact timestamp the user accepted the terms and conditions field. If the field becomes unchecked it should reset this column as well. This is to handle keeping record of consent. Registration Date in most cases is sufficient, but doesn't cover all cases like an additional column would. Since consent needs to be bundled with identifiable information this is by far the simplest approach that won't require a separate database table or anything of the sort.
Updated by krileon over 6 years ago
- Target version changed from CB 2.2 to CB 2.8
Updated by krileon about 6 years ago
In addition to this extend the terms and conditions fieldtype to check for consent. If the field is marked required and the user hasn't consented then don't let them leave profile edit until they consent. Since consent timestamp will be tracked implement support for expiration of consent (e.g. consent lasts 1 year) to require re-consent. This would cover all GDPR usecases and no longer need to use Joomlas built in privacy consent plugin.
Updated by beat about 6 years ago
Actually, if it is a "Log", it should probably keep a trace of prior consents and "un-consents", possibly with a copy of the terms agreed to lol.
Now there is also an edge case: If a user asks deletion or delete himself, his consents should still be kept, as well as a trace of his request of deletion. But all logs should be erased except the needed ones, so there are good reasons to keep the consents and logs but not the user record.
My sentiment here is that due to the evolving regulatory environment and possibly very data-heavy (btw actually GDPR requires to keep way more personal log data then before) and the fact that for speed-reasons, operative user-tables (user, comprofiler) should remain sleek and efficient, all privacy-management regulatory compliance data should remain separate from the data itself.
It is like the general good practice to keep meta-data separate from the data itself.
Thus my vote here would be to have a separate logging table, not only for privacy, but for all user changes. Possibly the CB Profile Update Logger's table could be a good place, and in this case just make its table core, and use it in CB core to log the consents and un-consents.
Regarding blocking access when no consent is given, that should probably be more flexible, just barring profile edit seems not to cover most use-cases imho.
Thoughts?
Updated by krileon about 6 years ago
- Status changed from Assigned to Resolved
- % Done changed from 0 to 100
Doesn't need to be a full action log (we won't need to track prior consent), which is already covered by CB Profile Update Logger and Joomlas Privacy Suite Action Log, we just need to log when the user accepted the terms field (latest accepted datetime). So a second column for terms and condition fieldtypes is all we need to cover that requirement. Blocking access is required as the user either needs to accept the terms or basically ask to be deleted (they can access com_privacy and CB Privacy to do this). The blocking is optional and default disabled as there's no need to force consent verify on every site immediately as it'd cause mass confusion I'm sure. In addition to that our blocking behavior allows the admin to add exceptions (e.g. can specify URLs the user is still allowed to access via parameter and so can plugins via trigger).
Implemented improved terms and conditions field behavior in MR !1429