feat: project templates and shareable links #4154

njhale · 2025-09-05T07:24:24Z

Addresses the bulk of #4107

Loom: https://www.loom.com/share/964fd03595814f92a8072df77b95634d?sid=45918fb2-f0be-4c76-bfa9-1e7a59308a41

To be addressed in a follow-up:

Preventing users from copying projects containing MCP servers they
don't have access to
Preventing copied project upgrades when the user doesn't have access
to MCP servers in the latest snapshot

njhale · 2025-09-08T05:07:58Z

pkg/api/handlers/projectmcp.go

@@ -56,7 +56,7 @@ func convertProjectMCPServer(projectServer *v1.ProjectMCPServer, mcpServer *v1.M
 	}
 	pmcp.Alias = mcpServer.Spec.Alias

-	if cred != nil && mcpServer.Spec.SharedWithinMCPCatalogName == "" {
+	if mcpServer.Spec.SharedWithinMCPCatalogName == "" {


Note: I removed the cred != nil check because it was preventing the fields below from being set for "copied" mcp servers

njhale · 2025-09-11T00:35:31Z

pkg/api/handlers/mcp.go

@@ -210,6 +210,10 @@ func (m *MCPHandler) ListServer(req api.Context) error {
 	items := make([]types.MCPServer, 0, len(servers.Items))

 	for _, server := range servers.Items {
+		if server.Annotations[v1.HideMCPServerAnnotation] == "true" {


This prevents users from seeing the snapshot project's (potentially unconfigured/unauthenticated) MCP servers in their set of enabled connectors.

These MCP servers are part of the snapshot resources that get copied by users when they hit a share link or upgrade their project.

Does it make sense for these to be separate object types instead of having a tracking annotation?

So something like TemplateMCPServer for example?

For reference, #4154 (comment) explains why I did this with the same objects (to reuse copying logic).

njhale · 2025-09-11T00:48:30Z

pkg/api/handlers/threads.go

+	}
+
+	// Populate ProjectSnapshotRevision from annotation if present
+	if ts := thread.Annotations[v1.ProjectSnapshotRevisionAnnotation]; ts != "" {


v1.ProjectSnapshotRevisionAnnotation is just an informational timestamp so publishers and consumers can reason about when a snapshot was last updated. It could also be a status field on the thread that gets set after an upgrade has finished.

+1 for status field

njhale · 2025-09-11T01:10:07Z

pkg/controller/handlers/threads/threads.go

-			continue
-		} else if err != nil {
+	// Delete all existing tasks for this thread
+	var existing v1.WorkflowList


I changed this to copy all tasks

Just noticed that there's a side-effect here that causes task threads to get nuked when you upgrade from a template. I would like to follow up with a fix for this if possible.

njhale · 2025-09-11T01:12:19Z

pkg/storage/apis/obot.obot.ai/v1/thread.go

+	// - introduction message
+	// - starter messages
+	// - tool set
+	// - tasks
+	// - knowledge files
+	// - model provider
+	// - model
+	// - prompt
+	// - allowed MCP tools
+	// - project MCP servers


I've since dropped some of these from the hash since they didn't feel like they would be destructive (e.g. allowed MCP tools).

I think these all make sense.

For allowed tools for example, if I change them myself, then I won't ever be able to upgrade from the template again. What if the next upgrade of the template has the allowed tools list that I need?

That's a fair point, Ill add it back.

njhale · 2025-09-11T01:13:06Z

ui/user/src/lib/components/agents/AgentCatalog.svelte

@@ -1,262 +0,0 @@
-<script lang="ts">


Dropped this since it wasn't being used and simplified things a bit

njhale · 2025-09-11T01:13:55Z

ui/user/src/lib/components/agents/AgentCopy.svelte

@@ -1,6 +1,5 @@
 <script lang="ts">


Planning on moving this to a more aptly named component/directory down the road.

ui/user/src/lib/components/chat/McpServerRequirements.svelte

thedadams

Overall, I think it is worth considering separate objects for the copied template objects like threads, MCP servers, project MCP servers, tasks, etc (I'm sure I missed a few). This would avoid some of the boolean flags and the fields to keep objects from showing up in the API requests.

pkg/api/authz/template.go

pkg/api/handlers/projectmcp.go

pkg/api/handlers/projects.go

thedadams · 2025-09-11T12:52:21Z

pkg/api/handlers/threads.go

+	}
+
+	// Populate ProjectSnapshotRevision from annotation if present
+	if ts := thread.Annotations[v1.ProjectSnapshotRevisionAnnotation]; ts != "" {


+1 for status field

pkg/controller/handlers/threads/template.go

pkg/controller/handlers/threads/threads.go

ui/user/src/lib/components/chat/McpServerRequirements.svelte

njhale · 2025-09-11T15:15:36Z

@thedadams yeah, I had the same thought. WDYT about a single Template resource that contains each of the objects that needs to be copied, instead of having separate Template* resources for each one?

Also, FWIW, the reason it isn't this way in the PR currently is to reuse most of the same logic between:

copying a project thread and its resource to a template thread
copying a template thread and its resources to a consumer project

njhale · 2025-09-16T17:13:55Z

So I stuck with copying existing resource types since it was more straightforward.

@thedadams @ivyjeong13 requesting another round of review to try to get this in

njhale · 2025-09-16T17:33:24Z

hmm, go lint isn't failing locally. Checking it out.

Addresses the bulk of obot-platform#4107 To be addressed in a follow-up: - Preventing users from copying projects containing MCP servers they don't have access to - Preventing copied project upgrades when the user doesn't have access to MCP servers in the latest snapshot Signed-off-by: Nick Hale <[email protected]>

njhale · 2025-09-16T18:04:00Z

hmm, go lint isn't failing locally. Checking it out.

had a stale local work tree. fixed

ivyjeong13

https://www.loom.com/share/0f48e1839e0c4940a94c2e3596088266

Think there's one more location that could use the dontLogErrors for the reveal endpoint! (Loom above for reference) Also thinking the init configure form data could be turned into a common function since some form of it is being used in a few locations now. But that's more of a note to myself, not PR blocking! : ) Frontend changes LGTM

Frontend changes LGTM

Signed-off-by: Nick Hale <[email protected]>

njhale · 2025-09-16T19:52:11Z

@ivyjeong13 Thanks for the review and actually taking the time to run this!

Think there's one more location that could use the dontLogErrors for the reveal endpoint!

nice catch. I'll fix that ASAP

pkg/api/handlers/projects.go

pkg/api/handlers/template.go

pkg/api/handlers/threads.go

pkg/storage/apis/obot.obot.ai/v1/thread.go

pkg/controller/handlers/threads/template.go

… logs This fixes the issue Ivy was seeing with error toasts being exposed during initial MCP server configuration after a template copy. Signed-off-by: Nick Hale <[email protected]>

njhale · 2025-09-16T20:39:15Z

@ivyjeong13 done

Signed-off-by: Nick Hale <[email protected]>

njhale force-pushed the feat/templates-reloaded branch from 3662209 to 4501198 Compare September 5, 2025 07:31

njhale commented Sep 8, 2025

View reviewed changes

njhale force-pushed the feat/templates-reloaded branch 4 times, most recently from fc72494 to fcefcf2 Compare September 10, 2025 21:40

njhale changed the title ~~Enable project snapshot sharing~~ feat: project templates and shareable links Sep 10, 2025

njhale force-pushed the feat/templates-reloaded branch from fcefcf2 to 8fe8595 Compare September 11, 2025 00:27

njhale commented Sep 11, 2025

View reviewed changes

njhale requested review from ivyjeong13 and thedadams September 11, 2025 01:21

njhale commented Sep 11, 2025

View reviewed changes

ui/user/src/lib/components/chat/McpServerRequirements.svelte Show resolved Hide resolved

njhale force-pushed the feat/templates-reloaded branch from 8fe8595 to fd9e89a Compare September 11, 2025 01:25

thedadams reviewed Sep 11, 2025

View reviewed changes

ivyjeong13 reviewed Sep 11, 2025

View reviewed changes

ui/user/src/lib/components/chat/McpServerRequirements.svelte Show resolved Hide resolved

njhale force-pushed the feat/templates-reloaded branch 3 times, most recently from 742baf8 to fdd7d7a Compare September 16, 2025 17:13

njhale marked this pull request as ready for review September 16, 2025 17:13

njhale requested review from cjellick and StrongMonkey September 16, 2025 17:13

njhale force-pushed the feat/templates-reloaded branch from fdd7d7a to 951e4eb Compare September 16, 2025 17:50

ivyjeong13 approved these changes Sep 16, 2025

View reviewed changes

fix: prevent connections to mcp templates in mcpgateway

61761c5

Signed-off-by: Nick Hale <[email protected]>

thedadams reviewed Sep 16, 2025

View reviewed changes

fix: prevent reveal errors from being presented in toasts and console…

b8d2c84

… logs This fixes the issue Ivy was seeing with error toasts being exposed during initial MCP server configuration after a template copy. Signed-off-by: Nick Hale <[email protected]>

chore: address feedback

1bfd769

Signed-off-by: Nick Hale <[email protected]>

njhale requested a review from thedadams September 16, 2025 21:47

thedadams approved these changes Sep 17, 2025

View reviewed changes

njhale merged commit 4ba683f into obot-platform:main Sep 17, 2025
5 checks passed

feat: project templates and shareable links #4154

feat: project templates and shareable links #4154

Uh oh!

Conversation

njhale commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

thedadams left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

njhale commented Sep 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

njhale commented Sep 16, 2025

Uh oh!

njhale commented Sep 16, 2025

Uh oh!

njhale commented Sep 16, 2025

Uh oh!

ivyjeong13 left a comment

Choose a reason for hiding this comment

Uh oh!

njhale commented Sep 16, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

njhale commented Sep 16, 2025

Uh oh!

njhale commented Sep 5, 2025 •

edited

Loading

njhale commented Sep 11, 2025 •

edited

Loading