You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature: optional storage_path prefix for uploads #53
Hello, really nice project, saved us a pile of code.
Quick context: we're wiring your server into an internal orchestration platform where each task has a logical job/task namespace. Files land in a shared MinIO bucket that already holds other artifacts, so every generated .pptx/.docx/.eml ends up flat in the bucket root next to hundreds of unrelated objects. For us the natural layout would be something like jobs/<job_id>/<task_id>/deck.pptx — same namespace as our other outputs.
I tried smuggling the path into file_name first. That correctly gets scrubbed by sanitize_filename before upload, so slashes vanish and the ids just concatenate into one long filename. Makes sense — you don't want callers pushing ../ into the bucket.
Would you be open to a PR that adds an optional storage_path argument to the create_* tools, kept separate from file_name? Rough shape I had in mind:
-file_name keeps working exactly as it does now (leaf name only, slashes stripped)
-new storage_path: str | None, validated through its own function — allow [A-Za-z0-9_/-], reject .., absolute paths, null bytes, leading /
-upload_file prepends it to the final object key with a / separator
-Fully optional, defaults to empty, no effect on existing calls.
On top of that, a server-wide STORAGE_PATH_PREFIX env would be nice so the host platform can set a default namespace without each caller passing it — but that's secondary, happy to split it into a second PR.
Happy to PR this if the direction works. Tell me if you'd rather do it differently.
Activity
dvejsada commentedon Jun 14, 2026
@bbokun Sorry for late reply. It is of course welcomed, provided that it is implemented as optional to user to opt-in.