Adds a "Continue this chat" button to the shared conversation view that forks
the shared conversation into a new conversation owned by the viewer and opens it
to continue (issue #13001).
- POST /api/share/:shareId/fork, gated by requireJwtAuth, the fork rate
limiters, and the canAccessSharedLink ACL (view access = fork access).
- forkSharedConversation clones from the anonymized getSharedMessages payload,
so only share-visible data is copied.
- Strips file ids from cloned files/attachments so a fork grants no more file
access than viewing the read-only share, and honors the global shared-file
kill switch via the snapshotFiles option.
- Reduces the clone to the viewer's active branch, located by its index in the
shared payload (shared ids are re-anonymized per request and createdAt can
collide, while the payload order is stable).
- Resolves config/retention, persists, and reads back under the requesting
user's tenant, not the share owner's; canAccessSharedLink also falls back to
a system-wide share lookup so cross-tenant public shares resolve (ACL still
enforced under the share's own tenant).
- Resolves a usable endpoint/model from the viewer's models config instead of
hard-coding OpenAI, so deployments without OpenAI can send the first message.
- Routes the fork's 401s (logged-out or cold-loaded viewers) through login,
including when the refresh itself is rejected for a stale session.
- Hides the Temporary Chat toggle once a conversation has a real id, and
portals the share-settings theme/language dropdowns above the dialog.
Rebased onto dev; collapses the share-fork feature and its review fixes into a
single commit.
* 📥 fix: Use Endpoint-Aware Default Model on Imported Conversations
Claude conversations imported from claude.ai's data export display
"gpt-4o-mini" in the chat UI until the page is refreshed, and any
attempt to send a message before refreshing fails with "The model
'gpt-4o-mini' is not available for Anthropic."
Root cause: ImportBatchBuilder.finishConversation() unconditionally
defaulted the saved conversation's `model` field to
openAISettings.model.default, regardless of `this.endpoint`. Claude
exports don't carry a model name, so every imported Claude conversation
landed with endpoint=anthropic but model=gpt-4o-mini.
Fix: pick the default based on `this.endpoint` via a small lookup
(openAI -> gpt-4o-mini, anthropic -> claude-3-5-sonnet-latest), keeping
the existing OpenAI default as the fallback for unknown endpoints.
Fixes#12844
* 🪄 refactor: Resolve Import Default Model From `modelsConfig`
Replace the hardcoded per-endpoint default lookup added in the previous
commit with a runtime resolver that consults the same models config the
chat UI uses (`getModelsConfig` in ModelController -> `loadDefaultModels`
+ `loadConfigModels`). This way an imported conversation defaults to a
model the LibreChat instance has actually configured / discovered for
the endpoint, instead of a hardcoded constant that may not exist on this
deployment.
Resolution order:
1. First non-empty model in `modelsConfig[endpoint]`.
2. Per-endpoint hardcoded fallback (anthropic/openAI settings) if the
runtime config is empty for the endpoint or `getModelsConfig` throws.
3. `openAISettings.model.default` if even the per-endpoint fallback is
missing (unknown endpoint).
`importBatchBuilder.finishConversation` now accepts an optional
`defaultModel` argument; each importer resolves it once at the top via
`resolveImportDefaultModel({ endpoint, requestUserId, userRole })` and
threads it through. ChatGPT message-level model selection also falls
back to the resolved default before the hardcoded gpt-4o-mini.
