User tests: Successful: Unsuccessful:
Pull Request for Issue joomla-projects/privacy-framework#242.
Change the 'where' clause to properly apply remind, expiration and user consented status by namespacing consents based on the 'subject' field.
Refer to issue joomla-projects/privacy-framework#242
Test that the privacyconsent plugin only manages the state of consents of the core PLG_SYSTEM_PRIVACYCONSENT_SUBJECT
Consents stored in the #__privacy_consents table by third-party extensions must not be affected nor affect the working mode of the privacyconsent plugin.
Status | New | ⇒ | Pending |
Category | ⇒ | Front End Plugins |
Title |
|
Another thing to consider for this PR: in this way we force any other 3rd party implementation to add their own remindExpiringConsents function. It will require some work, but it might be nice to make that more optional. So adding consents without the requirement to have all functions in your own plugin.
I agree @sanderpotjer but i think it's better leave it as now for the onUserAfterDelete function, it's perfectly acceptable to delete even third-party consents upon a user deletion.
For the other thing, it's up to third-party extensions to choose if the consents must have an expiration time or not. Not in all cases this is required and could be done even in a manual way.
Another thing to consider for this PR: in this way we force any other 3rd party implementation to add their own remindExpiringConsents function. It will require some work, but it might be nice to make that more optional.
The code in the core plugins is really geared toward the core features/workflow, some of it may work for third party but not always.
With that said, some work started on a core job/cron type system since we've been adding a lot of plugins lately that have a cron-like schedule (either hardcoded or configurable). I'd say that with that job system in place, a lot of the logic for the remind/invalidate stuff could move into a component helper class with parameters for key values that could more easily be re-used. Until we get there though, since plugins aren't really part of the API, we're fine with this as is.
if someone is interested in core job/cron type system
joomla-projects/privacy-framework#133
joomla-projects/privacy-framework#217
Thanks guys,
Labels |
Added:
?
|
Status | Pending | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-09-09 17:10:18 |
Closed_By | ⇒ | mbabker |
I have tested this item✅ successfully on c460371
I could argue that the subject should also be taken into account for the onUserAfterDelete function if you really want "Consents stored in the #__privacy_consents table by third-party extensions must not be affected nor affect the working mode of the privacyconsent plugin."
But at the other hand it is the only way to make sure that all user related consents are deleted upon deleting a user, also if 3rd party extensions "Forget" to implement the onUserAfterDelete.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/22047.