Problem
Cloud storage operations through daptin-cli currently require using the generic execute command with raw action parameters. The setup workflow alone is 4 separate API calls (create credential, create cloud_store, PATCH relationship link, restart server), and file uploads require manual base64-encoding into the [{name, file, type}] array format.
There is no dedicated download command at all.
Proposed: daptin-cli storage subcommand
Store management — collapse multi-step setup into one command
# One command handles: credential creation, cloud_store creation, relationship linking
daptin-cli storage add minio \
--type s3 \
--provider Minio \
--endpoint http://localhost:9000 \
--access-key minioadmin \
--secret-key minioadmin123 \
--bucket daptin-test
daptin-cli storage list
daptin-cli storage remove minio
File operations — filesystem-style UX
daptin-cli storage ls minio:/path/
daptin-cli storage upload minio:/photos/ ./local-file.jpg
daptin-cli storage upload minio:/docs/ ./folder/ # recursive
daptin-cli storage download minio:/photos/img.jpg ./
daptin-cli storage mv minio:/old-path minio:/new-path
daptin-cli storage rm minio:/photos/img.jpg
daptin-cli storage mkdir minio:/new-folder
Asset column uploads — the other upload path
daptin-cli asset upload product <ref-id> photo ./image.png
daptin-cli asset list product <ref-id> photo
Key design points
storage add is the big win — it removes the most friction (4 API calls → 1 command)- File upload should handle base64 encoding, chunking, and the
[{name, file, type}] array format internally
- Large files should use the streaming upload endpoint (
/asset/.../upload) instead of base64 action
store-name:/path addressing mirrors rclone convention which daptin already uses internally- Recursive upload for directories
Context
Cloud storage credential format must include rclone-compatible fields (type, provider, etc.) — the CLI should know the required fields per provider and prompt or validate accordingly.
The server requires a restart after cloud_store creation to pick up the new config. The CLI should either trigger a restart action or warn the user.
Problem
Cloud storage operations through daptin-cli currently require using the generic
executecommand with raw action parameters. The setup workflow alone is 4 separate API calls (create credential, create cloud_store, PATCH relationship link, restart server), and file uploads require manual base64-encoding into the[{name, file, type}]array format.There is no dedicated download command at all.
Proposed:
daptin-cli storagesubcommandStore management — collapse multi-step setup into one command
# One command handles: credential creation, cloud_store creation, relationship linking daptin-cli storage add minio \ --type s3 \ --provider Minio \ --endpoint http://localhost:9000 \ --access-key minioadmin \ --secret-key minioadmin123 \ --bucket daptin-test daptin-cli storage list daptin-cli storage remove minioFile operations — filesystem-style UX
daptin-cli storage ls minio:/path/ daptin-cli storage upload minio:/photos/ ./local-file.jpg daptin-cli storage upload minio:/docs/ ./folder/ # recursive daptin-cli storage download minio:/photos/img.jpg ./ daptin-cli storage mv minio:/old-path minio:/new-path daptin-cli storage rm minio:/photos/img.jpg daptin-cli storage mkdir minio:/new-folderAsset column uploads — the other upload path
Key design points
storage addis the big win — it removes the most friction (4 API calls → 1 command)[{name, file, type}]array format internally/asset/.../upload) instead of base64 actionstore-name:/pathaddressing mirrors rclone convention which daptin already uses internallyContext
Cloud storage credential format must include rclone-compatible fields (
type,provider, etc.) — the CLI should know the required fields per provider and prompt or validate accordingly.The server requires a restart after cloud_store creation to pick up the new config. The CLI should either trigger a restart action or warn the user.