Page Comparison

...

...

Summary

Adds the ability to configure custom (granular) deletion policies for posts for specific teams and/or channels so that when . When the daily retention job runs it can selectively delete those resources selectively deletes posts by age based on what’s configuredthe configuration.

The retention job (or at least the queries) will have to be modified such that the global setting does not delete posts for any team or channel that is configured via granular policies. The granular policies completely override the global setting. Put another way a granular setting can cause a post to live longer or shorter than the global setting

The feature requires some new APIs, some new tables, and an edit to the existing data retention job logic.

API

Global Policy (existing API)

GET /api/v4/data_retention/policy to retrieve retrieves the global retention settings.

{
    "message_deletion_enabled": false,
    "file_deletion_enabled": false,
    "message_retention_cutoff": 0,
    "file_retention_cutoff": 0
}

...

The JSON object reflects the fields in the DataRetentionSettings config object for:

• EnableMessageDeletion

• EnableFileDeletion

• MessageRetentionDays

• FileRetentionDays

Updates to the global retention policy continues to be managed via the config APIAPIs.

...

Retention Policies

POST /api/v4/retention_policies to create a new retention policy.

Request:

{
    "display_name": "foo",
    "post_duration": 4
}

Response201 response:

{
    "id": "m8zoumpj9pn9zexospoxi5dzoc",
    "display_name": "foo",
    "post_duration": 4
}

...

PUT /api/v4/retention_policies/:policy_id/patch to patch patches a retention policy.

Request:

{
    "display_name": "foo2",
    "post_duration": 365
}

200 Response:

{
    "id": "m8zoumpj9pn9zexospoxi5dzoc",
    "display_name": "foo2",
    "post_duration": 365
}

...

GET /api/v4/retention_policies/:policy_id to get gets a retention policy by id.

{
    "id": "m8zoumpj9pn9zexospoxi5dzoc",
    "display_name": "foo2",
    "post_duration": 365,
    "teams": [
        {
            "id": "z7rxbxbfb7yxdydxzi8pestath",
            "display_name": "My Team 1"
        }
    ],
    "channels": [
        {
            "id": "z7rxbxbfb7yxdydxzi8pestath",
            "display_name": "Off Topic",
            "team_display_name": "My Team 1"
        }
    ]
}

...

DELETE /api/v4/retention_policies/:policy_id to delete deletes a retention policy.

As a prerequisite one must delete Deleting a RetentionPolicies record also deletes all of the associated RetentionPoliciesChannels and RetentionPoliciesTeams first, otherwise the request is rejected records.

...

GET /api/v4/retention_policies to list lists all retention policies, including associated teams and channels.

{
    "policies": [
        {
            "display_name": "foo",
            "post_duration": 2,
            "teams": ["z7rxbxbfb7yxdydxzi8pestath"],
                {
                    "channelsid": ["z7rxbxbfb7yxdydxzi8pestath"],
          }     ],     "totaldisplay_countname": "My Team 1
}

TBD: How much easier is it to just include the team and channel display names rather than just ids? For example:

{"
     "policies": [         { }
           "display_name": "foo" ],
            "post_durationchannels": [
2,               "teams": [{{
                    "id": "z7rxbxbfb7yxdydxzi8pestath",
"display_name": "My Team 1"}],                 "channels": [{"id": "z7rxbxbfb7yxdydxzi8pestath", "display_name": "Off Topic",
                    "team_display_name": "My Team 1"
                }
            ]
        }
    ],
    "total_count": 1
}

...

Retention Policies Teams

POST /api/v4/retention_policies/:policy_id/teams to associate associates a team to a retention policy.

Request:

{
    "team_idids": ["z7rxbxbfb7yxdydxzi8pestath"]
}

Response:

{
    "success_ids": ["z7rxbxbfb7yxdydxzi8pestath"],
    "failure_ids": []
}

Because a teams can only be associated to a single granular retention policy, we must specify which teams failed.

...

DELETE /api/v4/retention_policies/:policy_id/teams/:team_id to remove removes a team from a retention policy.

...

Retention Policies Channels

POST /api/v4/retention_policies/:policy_id/channels to associate associates a channel to a retention policy.

Request:

{
    "channel_idids": ["z7rxbxbfb7yxdydxzi8pestath"]
}

Response:

{
    "success_ids": ["z7rxbxbfb7yxdydxzi8pestath"],
    "failure_ids": []
}

Because a channel can only be associated to a single granular retention policy, we must specify which channels failed.

...

DELETE /api/v4/retention_policies/:policy_id/channels/:channel_id to delete deletes a channel from a retention policy.

...

Database

RetentionPolicies table

...

TBD: Does ChannelId need to be indexed?

RetentionPoliciesTeams table

TBD: Does TeamId need to be indexed?

Model

• Rename DataRetentionPolicy to GlobalDataRetentionPolicy

• Add RetentionPolicy representing a record in the RetentionPolicies table.

• Add RetentionPolicyChannel representing a record in the RetentionPoliciesChannels table.

• Add RetentionPolicyTeam representing a record in the RetentionPoliciesTeams table.

Enterprise

Changes to various methods on DataRetentionWorker in data_retention/worker.go are required.

We need a new query to determine the Posts records to be deleted, the output of which can be a list of post ids to be used to delete Posts records and the following:

• Reactions

• Preferences (of Category ‘flagged_post’)

• Threads

• ThreadMemberships

• LinkMetadata TBD: these aren’t currently purged via data retention, but they probably should be.

FileInfo (and their associated files on disk) and ChannelMemberHistory continue to be deleted system-wide with no new granularity.

TBD: Why is ChannelMemberHistory currently deleted as part of message retention days settings?

Mobile

No changes. Existing file-deleted and post-deleted UX covers all.