Discussion: Demo models only save to local filesystem

[Ajith-Penmatsa-GGL]

Demo models fail to route correctly when selected from git providers (GitHub/GitLab/Bitbucket). The demo selection currently hardcodes routing to localThreatModel, which bypasses the repository and branch selection workflow required for git providers.

When a user authenticated with a git provider selects a demo model, they are routed directly to a local threat model view instead of being prompted to:

1. Select a repository
2. Select a branch
3. Save the demo model to their git repository

This prevents users from properly creating threat models from demo templates in their git repositories.

Expected behaviour:

Demo model selection should respect the current provider context:

• Git providers (GitHub/GitLab/Bitbucket): After selecting a demo model, users should be routed to the repository selection page, then branch selection, and finally the model should be created in their chosen git repository
• Local/Desktop providers: After selecting a demo model, users should be routed directly to the threat model summary page
• Google provider: Similar to local/desktop, route directly to model summary.

Environment:

• Version: 2.5.0
• Platform: Web App
• OS: Windows
• Browser: Chrome

To Reproduce:

1. Navigate to Threat Dragon web app
2. Log in with a git provider (GitHub/GitLab/Bitbucket)
3. From the dashboard, click "Demo Models"
4. Select any demo model (e.g., "Online Game")
5. Observe that you are taken directly to a local threat model view
6. Attempt to save the model - no repository/branch context exists, and since provider type is set to git we will be using git routes when we try save , which would return 404 without that info.

Root Cause:

The SelectDemoModel.vue component hardcodes the route to localThreatModel regardless of the selected provider:

Declaration:

By submitting this issue you have:

• read the contribution guide and agree to the Code of Conduct
• not used agentic or generative AI in creating this bug report

The malformed API request URL /api/threatmodel///Internet%20of%20Things%20(IoT)%20Device/update shows missing {repo} and {branch} parameters (indicated by the three consecutive slashes ///), which should have been set during repository and branch selection a workflow that was incorrectly bypassed.

[jgadsden]

Thanks for reporting this @Ajith-Penmatsa-GGL , much appreciated
If you have a fix implmenertation that would be great, otherwise I hope someone from the community can fix this

[Ajith-Penmatsa-GGL]

I've already implemented a fix in my local fork. Just need to add unit tests to cover the changes, then I'll open a PR for review.

[Ajith-Penmatsa-GGL]

hey @jgadsden ,

I've been working on a fix for this issue. And here is my approach to fix it:

1. Created a new loadDemos action that loads demo models without requiring repo/branch context
2. For git/google providers, clicking a demo now routes through repo/folder selection first (same flow as creating a new model), then opens the demo
3. For local/desktop providers, demos open directly as before

This ensures the save context exists before opening the demo.

One consideration: this adds extra steps for git/google users who just want to view a demo without saving.

Options I considered:

• Current fix: Always require context selection for git/google (consistent, but more steps)
• Alternative: Open demos directly, prompt for context only on save attempt

I went with the first approach for consistency with the "new model" flow. Happy to hear you thoughts on this approach or a different approach that you would prefer.

Ready to open a PR if this direction looks good.

[jgadsden]

Hello @Ajith-Penmatsa-GGL , I agree the first approach is better on balance
However, I have a concern that we are changing the functionality of Threat Dragon without considering what benefit it will provide

(edited) Further thoughts: I am now not sure that we should be using remote repos for the demo models, and that they should in fact always be saved locally
Their use is illustrative, and I suspect that not many are used as a starting point because they are specific
So I think the use case is where they are saved locally and if they are found useful and modified, then they are promoted to github / google / gitlab