Not a bug Deleting user does not delete all PII from database

[Kirby]

Affected version

2.0.6 Beta 2

Steps to Reproduce

1. Setup Bounce Handling and make sure that email validation is enabled in user registration options
2. On the frontend, register a new user with a non-existent email address outside of the domains handled by the SMTP-Server that is used by that board to trigger a bounce
3. Manually run cronjob Process email bounces
4. Check if the bounce does appear in Email bounce log
5. Delete the user created in step 2
6. Re-Check Email bounce log

Expected Result
The bounce is no longer being displayed as it was removed from the database

Actual Result
The bounce is still being displayed with the users email address

 

[Slavik]

A bounced email would be an invalid email.. therefore not Personal information.

 

[Kirby]

Not necessarily. It could have been bounced because the mailbox was full, temporarily disabled, the receiving mailserver had an extended outage (too long for the sending mailserver to keep it queued), etc.

This was just one easy to reproduce example.

 

[Slavik]

Well as far as keeping the records, im pretty sure they are deleted automatically after 30 days anyway if not actioned before. So given the allowed timeframes, would be a non-issue.

 

[Kirby]

Which "allowed timeframe" are you refering to?

Anyway, what's the point in keeping data refering to deleted users? Seems useless to me.

 

[S Thomas]

Useless to you, important to network and system admins.

 

[Kirby]

Not really either, network & systems admins have their own logging datasources.

Anyway, if this is not considered a bug it's not the end of the day - it's just another piece of code we have to add on our own

 

[Slavik]

Which "allowed timeframe" are you refering to?

Anyway, what's the point in keeping data refering to deleted users? Seems useless to me.

All GDPR requests have a 1 month time frame for replies/action.

 

[Kirby]

Which doesn't help much if the request comes in June 1st, a log entry does get generated June 30th and and the deletion is finally processed July 1st (for example)

 

[Slavik]

Which doesn't help much if the request comes in June 1st, a log entry does get generated June 30th and and the deletion is finally processed July 1st (for example)

But by the time they submit a request for the information afterwards, and you wait a month to reply, its gone

 

[StarArmy]

What if it's February?

 

[Sim]

In XF2 email bounce logs are indeed pruned after 30 days - this is hardcoded and not configurable.

When a user is deleted, the bounce log record is updated to remove the user_id (ie it is set to 0), but the record remains.

The comment in the code is "it's worth keeping these records, but disassociate them"

This is basically a sysadmin function though - a record of what actually happened, rather than a collection of personal information.

It is reasonable to retain logging information for a (short) period of time for audit and other sysadmin purposes.

Retaining the email bounce logs for 30 days without the association of other personal information should not cause you any problems.

I would suggest that it may be useful for XenForo to make the prune time configurable though? That way cautious administrators can set it to something lower than 30 days if they choose.

 

[Chris D]

Lots of valid points in this thread, but all things considered, we're leaning towards not needing any changes here.