MMXII

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.

One thing that I miss a lot in group promotions is a rule that fires when a user is (or is not) a member of a certain club. (Of course clubs have to be activated on the community for this.) This would add much more flexibility to automated promotions. Can you please consider adding this in a future release?

I think it would be a good solution if the V5 version had URL Replacements built into the engine not with external plugins. Something like WoltLab Suite has. Please think about it, because a lot of forums are foreign and have diacritics in links.

From the v4.7.12 changelog:
Added ability to disable or redirect PII data requests & account deletion.
So this means there will be an option to enable/disable these features? Nice! What about redirecting? Which cases does that cover?

When approving an account deletion request, the message says:
"Please confirm that you want to delete %s. The member's content will be left in the database, but flagged as Guest content."
What does this mean exactly? Will the content show up under an anonymous guest post, a post under the original username with an added "(Guest)" to it? And why is there no option to delete the user's content?
When deleting an account manually, we get all sorts of options. If that is really missing here, then I suggest you add this to account deletion requests.

@Stuart Silvester Thanks for the info.
Can you then please move this to your feedback forum? Because I think when deleting an account based on an account deletion request, the admin should get the same options like manually deleting a member, which is:
delete the user's posts hide the user's posts (with options to either keep the user's name or make it anonymous) keep the user's posts (also with options to either keep the user's name or make it anonymous)

I found an issue regarding author responses to reviews in the downloads app:
Create a downloads category where reviews are allowed, but only after a file actually has been downloaded. Upload a file in said category. Do NOT download it for yourself! (This is the usualy scenario, because the author of a file already has the file, so there will be not need to download it.) Log in as another user, download the file and leave a review. Now log in again as the file's author and try to respond to that review (again: WITHOUT downloading the file in the first place). Current behavior:
You are allowed to write an author's response. However when you try to submit the response, nothing happens (no error message and the response will not be added to the review).
Expected behavior:
The author should always be able to respond to a review, no matter if he has downloaded the file or not.

There are language strings in regard to the icons. I think they start with "icon_" (I have to take a look, if you want the exact names). Those strings must not (!) contain any text, or the icons in the AdminCP will not be displayed. You should check if you find any text there. I am pretty sure that this will be the issue here.

Yes

If you disable it, of courses. It is like any other plugin out there. You don’t have to disable it. 

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.

Very nice, thank you!
I really hope this (and the option to allow/disallow account deletion requests) will make their way into the core software.

@Stuart Silvester Thanks for the info.
Can you then please move this to your feedback forum? Because I think when deleting an account based on an account deletion request, the admin should get the same options like manually deleting a member, which is:
delete the user's posts hide the user's posts (with options to either keep the user's name or make it anonymous) keep the user's posts (also with options to either keep the user's name or make it anonymous)

Invision Community already offers to highlight staff replies. Now what I would love to see in the software is an option (button) with a staff answer container that allowes the user to jump to (and go back to) the next staff answer, if there is any in the same topic. In addition to that a filter option to only show staff answers within a topic would be highly appreciated, too.
Both features allow users to find somewhat "official" answers more easily, which can be key in a support-orientated community.
And, of course, this does not neccessarily have to be limited to forums. It can also work in comments below blog articels, files, galery pictures and albums etc.

@Stuart Silvester Thanks for the info.
Can you then please move this to your feedback forum? Because I think when deleting an account based on an account deletion request, the admin should get the same options like manually deleting a member, which is:
delete the user's posts hide the user's posts (with options to either keep the user's name or make it anonymous) keep the user's posts (also with options to either keep the user's name or make it anonymous)

@Stuart Silvester Thanks for the info.
Can you then please move this to your feedback forum? Because I think when deleting an account based on an account deletion request, the admin should get the same options like manually deleting a member, which is:
delete the user's posts hide the user's posts (with options to either keep the user's name or make it anonymous) keep the user's posts (also with options to either keep the user's name or make it anonymous)

When approving an account deletion request, the message says:
"Please confirm that you want to delete %s. The member's content will be left in the database, but flagged as Guest content."
What does this mean exactly? Will the content show up under an anonymous guest post, a post under the original username with an added "(Guest)" to it? And why is there no option to delete the user's content?
When deleting an account manually, we get all sorts of options. If that is really missing here, then I suggest you add this to account deletion requests.

I found an issue regarding author responses to reviews in the downloads app:
Create a downloads category where reviews are allowed, but only after a file actually has been downloaded. Upload a file in said category. Do NOT download it for yourself! (This is the usualy scenario, because the author of a file already has the file, so there will be not need to download it.) Log in as another user, download the file and leave a review. Now log in again as the file's author and try to respond to that review (again: WITHOUT downloading the file in the first place). Current behavior:
You are allowed to write an author's response. However when you try to submit the response, nothing happens (no error message and the response will not be added to the review).
Expected behavior:
The author should always be able to respond to a review, no matter if he has downloaded the file or not.

When approving an account deletion request, the message says:
"Please confirm that you want to delete %s. The member's content will be left in the database, but flagged as Guest content."
What does this mean exactly? Will the content show up under an anonymous guest post, a post under the original username with an added "(Guest)" to it? And why is there no option to delete the user's content?
When deleting an account manually, we get all sorts of options. If that is really missing here, then I suggest you add this to account deletion requests.

@Stuart Silvester Thanks for the info.
Can you then please move this to your feedback forum? Because I think when deleting an account based on an account deletion request, the admin should get the same options like manually deleting a member, which is:
delete the user's posts hide the user's posts (with options to either keep the user's name or make it anonymous) keep the user's posts (also with options to either keep the user's name or make it anonymous)

IPS should finally learn after all the years, that every time they add new feature they should ask themselves a question: "is per group permission required?" personally I miss it in many areas.

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.

Free plugin awaiting approval.

Support:
 
 

Thanks. I thought the profile picture was untentially missing (hence a bug), because both the notification in the menu and in the black popup bubble at the bottom looks "weird", since every other notification that I can remember has this profile picture.