change hardcoded downloaded zip log file name

[FrancYescO]

Describe the feature you would like to see

change
filename=container-logs-%s.zip
to
filename=<containername>-logs-%s.zip

and maybe
filename=<stackname>-logs-%s.zip

if downloading the aggregate

Describe how you would like to see this feature implemented

No response

Describe any alternatives you've considered

No response

[amir20]

I like it! Not sure I'll get to it any time soon.

[aatif101]

Hi, I'd like to work on this feature!

Currently:
The download filename is hardcoded as container-logs-<timestamp>.zip regardless of what's being downloaded [download.go: line:114]

Proposed implementation:

Single container download: Use <container-name>-logs-<timestamp>.zip

The container name is already accessible through containerService.Container.Name, so this is basically just swapping out the hardcoded prefix with the actual container name.

For multi-container downloads where all containers belong to the same stack/project, we can generate: <stack-name>-logs-<timestamp>.zip

For stack detection, we can extract labels from each container and resolve the stack name using the same priority order used on the frontend, so behavior stays consistent across UI and backend:

1. dev.dozzle.group
2. coolify.projectName
3. com.docker.stack.namespace
4. com.docker.compose.project

The idea here is:

• Collect candidate stack names from all selected containers
• If they all resolve to the same value -> use that as the filename prefix
• If they differ or don't exist -> treat it as a mixed selection

For mixed containers (no shared stack / inconsistent labels), we fall back to: merged-logs-<timestamp>.zip

Sanitize filenames to replace any invalid characters (like / or :) with underscores

The container info is already collected before setting the header, so this is mostly about determining the appropriate name based on the number of containers and their shared labels.

Let me know if this approach sounds good. I can implement this unless there's an objection.

[amir20]

1. Container name makes sense
2. It's hard to come up with a good name for multiple containers. The problem is that it can be based on many filters and each one having their own set of containers. So two ideas:
   a. The front end can suggest a name because a the time of downloading the UI knows the state
   b. Just say <x>-containers-logs-<timestampe>.zip

[aatif101]

That's a good point, I hadn't thought about all the different filter contexts that could trigger a download.

I think Option A (frontend suggests the name) would give the best user experience since the UI already knows if you're on a stack page, service page, merged view, etc. We could add an optional name query param to the download URL, and the backend would use it if provided.

For the fallback (Option B): <count>-containers-logs-<timestamp>.zip works well. it's simple and still tells something useful.

So maybe both? Frontend passes the name when it knows the context, backend falls back to the count when it doesn't. Happy to start with just the backend changes first if that's easier to review.