CB

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.

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?