CodeWizard

Not sure about the others, but for me group-based permissions allow me to moderate. Right now you can request pii data and account deletion over and over again, even if you have downloaded the data a second ago. And for every request the admin has to react and take action. So in those cases, in order to force a member to not spam this functionality, I would (temporarily) move him to a group that is not allowed to request this information.
Despite that at least a global on/off option is needed -- in order to have control whether or not you want to have this workflow. Again, even in the EU the right to be forgotten has limitations to it. Not everyone under every circumstances can refer to it, so there are situations where you don't want to offer these options.

This is something I just cannot understand. All the bugs aside these two features introduce a whole new workflow of having to deal with requests, approvals and rejections. Who thought it's a good idea to release this without an option to opt-out? Not every community needs this and not everybody is ready. Communities that aren't ready to handle this are basically forced to stay on an older version and miss out on all other improvements. Both of those features should be configurable.
I looked into disabling it via code hooks and things get even worse. While hooking \IPS\Member::canUseAccountDeletion does the trick for account deletion (proper backend checks + removes it from UI), same route just doesn't work for PII.
\IPS\Member\PrivacyAction::canRequestPiiData/canDownloadPiiData can be hooked but UI elements will stay because of settingsPrivacy template. Buttons will be gone but whole div, header and description will stay.
For account deletion whole div is wrapped properly:
{{if \IPS\Member::loggedIn()->canUseAccountDeletion() }} ... {{endif}} Why same thing wasn't done for PII? This would do the trick:
{{if \IPS\Member\PrivacyAction::canRequestPiiData() }} ... {{endif}} Now it's impossible to remove this without excessive trickery. Theme hooks won't really do the job as there is no way to select that specific div as it doesn't have a unique identifier (it's a generic div.ipsPadding). Documentation states that "you can use any of the selectors supported by jQuery" and that's simply wrong, actually not even a tiny fraction of selectors used by jQuery are supported. Only the most basic CSS selectors can be used and those don't allow to select e.g. parent elements.
I didn't expect that a monthly update will turn into such a headache that a simple ACP option could easily fix.
tl;dr Please make those features optional.

This is something I just cannot understand. All the bugs aside these two features introduce a whole new workflow of having to deal with requests, approvals and rejections. Who thought it's a good idea to release this without an option to opt-out? Not every community needs this and not everybody is ready. Communities that aren't ready to handle this are basically forced to stay on an older version and miss out on all other improvements. Both of those features should be configurable.
I looked into disabling it via code hooks and things get even worse. While hooking \IPS\Member::canUseAccountDeletion does the trick for account deletion (proper backend checks + removes it from UI), same route just doesn't work for PII.
\IPS\Member\PrivacyAction::canRequestPiiData/canDownloadPiiData can be hooked but UI elements will stay because of settingsPrivacy template. Buttons will be gone but whole div, header and description will stay.
For account deletion whole div is wrapped properly:
{{if \IPS\Member::loggedIn()->canUseAccountDeletion() }} ... {{endif}} Why same thing wasn't done for PII? This would do the trick:
{{if \IPS\Member\PrivacyAction::canRequestPiiData() }} ... {{endif}} Now it's impossible to remove this without excessive trickery. Theme hooks won't really do the job as there is no way to select that specific div as it doesn't have a unique identifier (it's a generic div.ipsPadding). Documentation states that "you can use any of the selectors supported by jQuery" and that's simply wrong, actually not even a tiny fraction of selectors used by jQuery are supported. Only the most basic CSS selectors can be used and those don't allow to select e.g. parent elements.
I didn't expect that a monthly update will turn into such a headache that a simple ACP option could easily fix.
tl;dr Please make those features optional.

This is something I just cannot understand. All the bugs aside these two features introduce a whole new workflow of having to deal with requests, approvals and rejections. Who thought it's a good idea to release this without an option to opt-out? Not every community needs this and not everybody is ready. Communities that aren't ready to handle this are basically forced to stay on an older version and miss out on all other improvements. Both of those features should be configurable.
I looked into disabling it via code hooks and things get even worse. While hooking \IPS\Member::canUseAccountDeletion does the trick for account deletion (proper backend checks + removes it from UI), same route just doesn't work for PII.
\IPS\Member\PrivacyAction::canRequestPiiData/canDownloadPiiData can be hooked but UI elements will stay because of settingsPrivacy template. Buttons will be gone but whole div, header and description will stay.
For account deletion whole div is wrapped properly:
{{if \IPS\Member::loggedIn()->canUseAccountDeletion() }} ... {{endif}} Why same thing wasn't done for PII? This would do the trick:
{{if \IPS\Member\PrivacyAction::canRequestPiiData() }} ... {{endif}} Now it's impossible to remove this without excessive trickery. Theme hooks won't really do the job as there is no way to select that specific div as it doesn't have a unique identifier (it's a generic div.ipsPadding). Documentation states that "you can use any of the selectors supported by jQuery" and that's simply wrong, actually not even a tiny fraction of selectors used by jQuery are supported. Only the most basic CSS selectors can be used and those don't allow to select e.g. parent elements.
I didn't expect that a monthly update will turn into such a headache that a simple ACP option could easily fix.
tl;dr Please make those features optional.

Those are very nice and much needed features! 👍 Really looking forward to it.
Will there be options to enable/disable either of these fontend buttons? Say, I'd like to have the button for account deletion requests, but not for PII data requests. Will there be options to optionally automate account deletion in some way? E.g. 14 days after an account request for deletion has been sent and with no admin reacting in this timeframe, the account will be gone automatically?

Please add group-based options to enable/disable pii data requests and account deletion requests so that these frontend options do not neccessarily show up for every user.

Yes, please! I second that (hence my feedback here and here). Ideally the permissions should be group-based (at the same place where anonymous logins can be allowed/disallowed).

This is something I just cannot understand. All the bugs aside these two features introduce a whole new workflow of having to deal with requests, approvals and rejections. Who thought it's a good idea to release this without an option to opt-out? Not every community needs this and not everybody is ready. Communities that aren't ready to handle this are basically forced to stay on an older version and miss out on all other improvements. Both of those features should be configurable.
I looked into disabling it via code hooks and things get even worse. While hooking \IPS\Member::canUseAccountDeletion does the trick for account deletion (proper backend checks + removes it from UI), same route just doesn't work for PII.
\IPS\Member\PrivacyAction::canRequestPiiData/canDownloadPiiData can be hooked but UI elements will stay because of settingsPrivacy template. Buttons will be gone but whole div, header and description will stay.
For account deletion whole div is wrapped properly:
{{if \IPS\Member::loggedIn()->canUseAccountDeletion() }} ... {{endif}} Why same thing wasn't done for PII? This would do the trick:
{{if \IPS\Member\PrivacyAction::canRequestPiiData() }} ... {{endif}} Now it's impossible to remove this without excessive trickery. Theme hooks won't really do the job as there is no way to select that specific div as it doesn't have a unique identifier (it's a generic div.ipsPadding). Documentation states that "you can use any of the selectors supported by jQuery" and that's simply wrong, actually not even a tiny fraction of selectors used by jQuery are supported. Only the most basic CSS selectors can be used and those don't allow to select e.g. parent elements.
I didn't expect that a monthly update will turn into such a headache that a simple ACP option could easily fix.
tl;dr Please make those features optional.