Fix: Enforce Scope-Based Uniqueness for Gateway Server Name, Gateway Server URL & Tool Name (Private/Team/Public visibility rules)

[rakdutta]

(Reference issue #945)

Background / Issue

Previously, Gateway Server Name, Gateway Server URL, and Tool Name were validated with a global unique constraint.

• Creating a Gateway Server or Tool with Private visibility prevented others from using the same name/URL, even in other teams.
• This blocked valid scenarios where these values should only be unique within their visibility scope.

Fix Implemented

Database Changes

• Added composite unique constraints to enforce scope-based uniqueness:
  • Private → (slug, owner_email, team_id) for Gateway Server Name, Gateway Server URL, and Tool Name
  • Removed the old global uniqueness constraint on slug and url.

Application Logic

• Added validation to enforce scope rules:
  • Private → DB constraint ensures uniqueness per (slug/url/tool_name, owner_email, team_id)
  • Team → Validation ensures no duplicates within the same team_id
  • Public → Validation ensures no duplicates globally

Expected Behavior After Fix

Visibility	Uniqueness Scope	Example Conflict
Private	(slug/url/tool_name, owner_email, team_id)	Blocked only if same user & same team
Team	(slug/url/tool_name, team_id)	Blocked if another user in the same team uses the same name, URL, or Tool Name
Public	(slug/url/tool_name) globally	Blocked if any user/team already created a public resource

Testing / Verification

• User A (Team 1, Private) can create gw_name, gw_url, tool_name.
• User B (Team 2, Private) can also create the same names/URL/tool ✅ allowed.
• Two users in the same team cannot create duplicate names, URLs, or Tools ❌ blocked.
• Public names, URLs, and Tools are restricted globally ❌ blocked.