[FEATURE]: Human-Readable Public Share Links using Usernames and Document Slugs

[Gautam25Raj]

Affected Apps / Packages

Studio (apps/studio), Server (apps/server)

Is your feature request related to a problem?

The previous share link system relied on random, token-based paths (/share/[token]) to display public resumes and documents.

1. Poor UX: Opaque token paths are hard to read/remember, and do not convey the user's professional identity (e.g., who the resume belongs to).

2. Performance Issues: Resolving token links required scanning and listing links dynamically, leading to potential N+1 query patterns when loading lists of documents.

Describe the solution you'd like

We have transitioned from the legacy random-token architecture to a vanity URL scheme matching the structure:
/share/[username]/[slug]

Key components of the solution:

1. Vanity URL Routing: Public routes now use /share/[username]/[slug] instead of random tokens.

2. User Namespace Uniqueness: Documents are scoped to the owner, ensuring the combination of userId and slug is unique.

3. Collision Safety: A slug generator handles collisions by automatically appending sequential suffixes (e.g. resume, resume-2, resume-3) if a user has multiple documents with the same name.

4. Backend Optimization: Removed unnecessary count and pagination queries in the share controllers, leveraging optimized unique index lookups (userId_documentId) and Redis caching key invalidations for public-readable paths.

5. Dashboard Integration: Restored the share configuration modal in the documents page so users can manage password protection, view counts, and copy the new dynamic URLs directly.

Describe alternatives you've considered

• Allowing Custom Share-only Slugs: We considered allowing users to define a custom path specifically for sharing that was decoupled from the document title. However, syncing it directly with the document title and slug provides a cleaner user experience that is self-explanatory and easier to manage.

Additional Context

No response