TSP

@Matt On deletion of members: 
Could there be an option to define the name to attribute to on that page directly? So we could input for example "Member 3312" (where 3312 would be their memberId). This will keep the discussion still somewhat reader friendly, so it would still be possible to differentiate different accounts as having written in the discussion, for readers reading old content. 
Alternatively let the Anonymize attribution do a md5 hash on the (memberId+some community specific value that is unlikely to be changed) and grab the first 8 letters or something. 

@Matt @Christopher Anderson Well, it's pseudonymized at least. We personally take this road, so it will be useful to me if IPS would provide the option to let us input our own value to give as the new attribution. You can argue people can comb through all of the quoted content in others members posts and get the information that way anyway, or you could argue that an advanced AI in the future could be able to figure out which users are different anyway based on writing style alone.
I see no need to make it harder for people to understand how the flow of a previous conversation has been (if you choose not to delete the content in the first place), it only makes things confusing. 
There are 4 potential options here: 
Continue to attribute to Name (currently in this update) Attribute to "Guest" only (currently in this update) Attribute to the given name <Admin inputs new name> Pseudonymize: The software generates a md5-hash based on some values there and then that does not retrieve any member data, just something like a timestamp + some other value and then gives that name to all content from that account before it's deleted. @Matt Will I be able to hook into it at least? 

@Matt On deletion of members: 
Could there be an option to define the name to attribute to on that page directly? So we could input for example "Member 3312" (where 3312 would be their memberId). This will keep the discussion still somewhat reader friendly, so it would still be possible to differentiate different accounts as having written in the discussion, for readers reading old content. 
Alternatively let the Anonymize attribution do a md5 hash on the (memberId+some community specific value that is unlikely to be changed) and grab the first 8 letters or something. 

@Matt On deletion of members: 
Could there be an option to define the name to attribute to on that page directly? So we could input for example "Member 3312" (where 3312 would be their memberId). This will keep the discussion still somewhat reader friendly, so it would still be possible to differentiate different accounts as having written in the discussion, for readers reading old content. 
Alternatively let the Anonymize attribution do a md5 hash on the (memberId+some community specific value that is unlikely to be changed) and grab the first 8 letters or something. 

But other parts of account history is unnesseary. 
For example, do you need to know that someone changed from mypreviousmail@myjob.com to unemployednow@yahoo.com for a year? You are perfectly able to make a good argument for keeping such entries for some months after the member changed it, but you're really stretching it when it goes beyond a year for some of the information they store to account history now. 

I'm glad you didn't say Sony Pictures ?
Great work IPS Team. The 3rd party/privacy policy integration is excellent. I take it the screenshot only shows which apps are integrated e.g. Send Grid won't show if you don't use it?
And I add my support to @TSP's brilliant suggestion.

Great update. Huge step in the right direction. ?
 
There is no debate about that. That has been determined time and time again by the highest of courts in Europe. IP addresses are personal information. ?
Thanks for the retention feature! Highly appreciated! I guess setting this to 0 days would make it fully compliant ?
yes!! Also this would allow to delete all of member 3312s' content even if the member itself was removed.
I am very pleased to see that IPS is finally taking action on this ? The remaining timeframe ist very very very very harsh unfortunately. 
Two things I still miss in your blog:
A data processing agreement Options to opt-in for each use of the comment, contact, posting feature with documented history (like you've implemented for admin bulk mails) I do miss the good old days with ikonboard. User credentials were stored unencrypted, no one cared. Better world back then ?

I like this idea.

Awesome idea @TSP, I'd like to see that.

@Matt On deletion of members: 
Could there be an option to define the name to attribute to on that page directly? So we could input for example "Member 3312" (where 3312 would be their memberId). This will keep the discussion still somewhat reader friendly, so it would still be possible to differentiate different accounts as having written in the discussion, for readers reading old content. 
Alternatively let the Anonymize attribution do a md5 hash on the (memberId+some community specific value that is unlikely to be changed) and grab the first 8 letters or something. 

@Matt On deletion of members: 
Could there be an option to define the name to attribute to on that page directly? So we could input for example "Member 3312" (where 3312 would be their memberId). This will keep the discussion still somewhat reader friendly, so it would still be possible to differentiate different accounts as having written in the discussion, for readers reading old content. 
Alternatively let the Anonymize attribution do a md5 hash on the (memberId+some community specific value that is unlikely to be changed) and grab the first 8 letters or something. 

@Matt On deletion of members: 
Could there be an option to define the name to attribute to on that page directly? So we could input for example "Member 3312" (where 3312 would be their memberId). This will keep the discussion still somewhat reader friendly, so it would still be possible to differentiate different accounts as having written in the discussion, for readers reading old content. 
Alternatively let the Anonymize attribution do a md5 hash on the (memberId+some community specific value that is unlikely to be changed) and grab the first 8 letters or something. 

@Matt On deletion of members: 
Could there be an option to define the name to attribute to on that page directly? So we could input for example "Member 3312" (where 3312 would be their memberId). This will keep the discussion still somewhat reader friendly, so it would still be possible to differentiate different accounts as having written in the discussion, for readers reading old content. 
Alternatively let the Anonymize attribution do a md5 hash on the (memberId+some community specific value that is unlikely to be changed) and grab the first 8 letters or something. 

@Matt On deletion of members: 
Could there be an option to define the name to attribute to on that page directly? So we could input for example "Member 3312" (where 3312 would be their memberId). This will keep the discussion still somewhat reader friendly, so it would still be possible to differentiate different accounts as having written in the discussion, for readers reading old content. 
Alternatively let the Anonymize attribution do a md5 hash on the (memberId+some community specific value that is unlikely to be changed) and grab the first 8 letters or something. 

@Matt On deletion of members: 
Could there be an option to define the name to attribute to on that page directly? So we could input for example "Member 3312" (where 3312 would be their memberId). This will keep the discussion still somewhat reader friendly, so it would still be possible to differentiate different accounts as having written in the discussion, for readers reading old content. 
Alternatively let the Anonymize attribution do a md5 hash on the (memberId+some community specific value that is unlikely to be changed) and grab the first 8 letters or something. 

@Matt On deletion of members: 
Could there be an option to define the name to attribute to on that page directly? So we could input for example "Member 3312" (where 3312 would be their memberId). This will keep the discussion still somewhat reader friendly, so it would still be possible to differentiate different accounts as having written in the discussion, for readers reading old content. 
Alternatively let the Anonymize attribution do a md5 hash on the (memberId+some community specific value that is unlikely to be changed) and grab the first 8 letters or something. 

@Matt On deletion of members: 
Could there be an option to define the name to attribute to on that page directly? So we could input for example "Member 3312" (where 3312 would be their memberId). This will keep the discussion still somewhat reader friendly, so it would still be possible to differentiate different accounts as having written in the discussion, for readers reading old content. 
Alternatively let the Anonymize attribution do a md5 hash on the (memberId+some community specific value that is unlikely to be changed) and grab the first 8 letters or something. 

More information will be made available about our position with regards to the GDPR in the next day or so and a few more provisions are being added to the software (this will be detailed more in the upcoming post) by the implementation deadline. Beyond that, I'd ask that you slow the roll so-to-speak on personal interpretations and armchair legalese for there is no need to get worked up into a frenzy. Much like Y2K when everyone thought the world was going to end, the power grid was going to shut down and we'd be left with a smoking pile of circuitry ashes - I assure you, May 26th will be uneventful and we will all carry on as normal - just with some additional data processing safeguards. The regulations will be further interpreted, tested via case law and the world (including IPS) will adapt accordingly. In the interim, please relax and wait for our next update this week. It should address the remaining concerns we've interpreted and determined to be valid. 
As an aside, the software does not prevent you from controlling content. It is not our position nor that of the numerous experts we've consulted with that contributed content to a public community-centric entity constitutes personal information in accordance with the GDPR. If you believe otherwise, the software allows you to delete that content upon receipt of a right to erasure request from a data subject. You can also include in your terms and conditions (which you can require your users to accept) verbiage that addresses copyright, if you so desire. All of this is your decision based on your (and ideally, your legal expert's) individual interpretation of applicable laws - we are just providing baseline tools based on our interpretation. 
Please stay tuned while we further address your GDPR concerns such as obtaining technical support, data portability, etc. 

FWIW I agree on the interpration from IPS on most points here. The only thing I'm a bit surprised by is that they don't provide retention settings for:
IP addresses Account history  Ironically, the "worth" of an IP address diminishes the longer it's stored, but I still feel this is one thing it would be appropiate to have a retention setting for. I will likely make a custom script for this in my case which will likely operate with two retention settings: 
One for members who have NOT been warned and/or suspended the last year One for members that have been warned and/or suspended the last year

I guess my most nerdy disposition is that I like to read through plans for and follow railroad projects closely. I'm a huge supporter of more rails transport!
Other than that it's mostly theatre (acting) and Netflix.

I guess my most nerdy disposition is that I like to read through plans for and follow railroad projects closely. I'm a huge supporter of more rails transport!
Other than that it's mostly theatre (acting) and Netflix.

Yeah we just saw it ourselves. What timing! ?

It not the same as just highlighting.

I don't like current behaviour of highlighting because it works for every posts, does not matter if this post important or not (i.e. "official staff answer" or "staff member's comment on kittens photo"). I'd prefer to have an option below editor. Posted this also as suggestion in feedback and ideas section. Please support(reaction/comment - any activity) this topic if you need it too.

If you get the question from your FTP client on a folder, you choose to merge with existing folders. When/if you then get the question on a file, you choose to overwrite existing files. That's what was meant by merge and overwrite. Because you want to merge folders (so no existing files that is not within your patch folder (but is within the selected folder on the server) gets deleted). You usually only get the merge option if it's about a folder. As merging an already existing file with a new file with the same name would not be an sensible option for an FTP client.
Some FTP-clients will provide the option of "Merge and overwrite" right away, which means it will merge folders and overwrite files.