Is there an existing issue for this?
Summary
Problem
Currently, when a template or building block is forked, the fork event (fork_APPLICATIONTEMPLATE) triggered on the backend only contains data pertaining to the destination application. However, crucial information about the template being forked is not included in this event. With the introduction of multiple template types, this lack of template application data poses challenges in tracking template usage by type and other fork event data related to the template/building block being forked.
Solution
To address the issue, we will enhance the forking process by including additional data in the POST request needed for forking templates. Specifically, we will include templateName, sourceForkedFrom, and templateType in the POST data. This information will then be logged in the event data on the backend when a template is forked.
Methodology
Inclusion of Additional Data: We will extend the forking process to include templateName, source, and templateType in the POST data required for forking templates.
Logging in Event Data: Upon forking, this supplementary data will be captured and logged in the event data on the backend.
Reasoning
Directly calling the template data in the backend would necessitate an extra API call to the CS backend since template data resides there, not in the platform backend. This would introduce redundancy and increase the overhead of the forking process. By passing the required template data in the initial POST request for forking templates, we eliminate the need for an additional API call to CS, streamlining the forking process and reducing redundancy.
Why should this be worked on?
This enhancement is crucial for improving tracking and analytics capabilities within the templates platform. By including comprehensive template data in the fork event, we enable better monitoring of template usage by type and provide valuable insights into fork events related to templates and building blocks.
Is there an existing issue for this?
Summary
Problem
Currently, when a template or building block is forked, the fork event (fork_APPLICATIONTEMPLATE) triggered on the backend only contains data pertaining to the destination application. However, crucial information about the template being forked is not included in this event. With the introduction of multiple template types, this lack of template application data poses challenges in tracking template usage by type and other fork event data related to the template/building block being forked.
Solution
To address the issue, we will enhance the forking process by including additional data in the POST request needed for forking templates. Specifically, we will include templateName, sourceForkedFrom, and templateType in the POST data. This information will then be logged in the event data on the backend when a template is forked.
Methodology
Inclusion of Additional Data: We will extend the forking process to include templateName, source, and templateType in the POST data required for forking templates.
Logging in Event Data: Upon forking, this supplementary data will be captured and logged in the event data on the backend.
Reasoning
Directly calling the template data in the backend would necessitate an extra API call to the CS backend since template data resides there, not in the platform backend. This would introduce redundancy and increase the overhead of the forking process. By passing the required template data in the initial POST request for forking templates, we eliminate the need for an additional API call to CS, streamlining the forking process and reducing redundancy.
Why should this be worked on?
This enhancement is crucial for improving tracking and analytics capabilities within the templates platform. By including comprehensive template data in the fork event, we enable better monitoring of template usage by type and provide valuable insights into fork events related to templates and building blocks.