[WIP] Technical Specification - Granular Data Retention

Summary

Adds the ability to configure custom (granular) deletion policies for posts for specific teams and/or channels so that when the daily retention job runs it can selectively delete those posts by age based on the 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 differently, granular setting can either 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 code.

API

Global Policy (existing API)

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

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

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

Retention Policies

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

Request:

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

201 response:

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

PUT /api/v4/retention_policies/:policy_id/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 gets a retention policy by id.

{
    "id": "m8zoumpj9pn9zexospoxi5dzoc",
    "display_name": "foo2",
    "post_duration": 365,
    "teams": ["z7rxbxbfb7yxdydxzi8pestath"],
    "channels": ["z7rxbxbfb7yxdydxzi8pestath"]
}

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

As a prerequisite one must delete all of the RetentionPoliciesChannels and RetentionPoliciesTeams first, otherwise the request is rejected.

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

{
    "policies": [
        {
            "display_name": "foo",
            "post_duration": 2,
            "teams": ["z7rxbxbfb7yxdydxzi8pestath"],
            "channels": ["z7rxbxbfb7yxdydxzi8pestath"]
        }
    ],
    "total_count": 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_duration": 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 associates a team to a retention policy.

Request:

{
    "team_id": "z7rxbxbfb7yxdydxzi8pestath"
}

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

Retention Policies Channels

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

Request:

{
    "channel_id": "z7rxbxbfb7yxdydxzi8pestath"
}

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

Database

RetentionPolicies table

RetentionPoliciesChannels table

RetentionPoliciesTeams table

Mobile

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