resource-duplication

Resource duplication

Your goal is to implement the configuration required to allow Django models to be copied from one team (project) to another.

Background

Resource duplication is a feature we offer to customers, which allows them to copy resources (ex: Dashboards, Insights, Feature Flags, etc.) from one team in their organization to another team in their organization.

Core concepts

Overview

Resources are duplicated by constructing a data-dependency graph between django models, topologically sorting each vertex in the graph, then iteratively duplicating each resource in the resulting directed acyclic graph.

Dependencies between models are detected from 1) django relations (ex: models.ForeignKeyField, related_name=, etc.), and 2) functions that extract foreign keys from JSON columns (in the code these are called dynamic edges).

Visitors

ResourceTransferVisitor is a python metaclass that must be implemented for each resource that we want to allow users to duplicate, or may need to handle during duplication. Importantly, it provides logic:

• The kind of the resource, referred to as scope in other parts of the code base like activity logs. Often just the name of the Django model.
• The fields that should be excluded when duplicating a resource (excluded_fields).
• If the resource should be allowed to be duplicated or left untouched (immutable).
• If the resource should be shown in the UI (user_facing).
• What is the Django model for the resource.
• What is the team for the resource.
• ...and more

If you want a resource to be able to be duplicated, you MUST create a visitor. Visitors are stored under posthog/models/resource_transfer/visitors. Each visitor must inherit from ResourceTransferVisitor defined in posthog/models/resource_transfer/visitors/base.py.

Your visitor's metaclass params and overloaded class methods will change how the resource is duplicated, so make sure to implement all fields that may be necessary.

Excluded fields