fix: make thumbnail generation for images in S3 configurable

[FloDwld]

This pull request adds a toggle to disable thumbnails for images stored in S3. The default value is to not generate thumbnails.

Fixes #5183

[Copilot]

Pull Request Overview

This PR adds a configurable setting to control thumbnail generation for images stored in S3. By default, thumbnails will not be generated for S3 images. Users can enable this feature through a toggle in the memo-related settings UI.

Key changes:

• Added useThumbnailsForS3Images boolean field to workspace memo-related settings (defaults to false)
• Modified backend attachment service to check this setting before generating thumbnails for S3 images
• Added UI toggle in settings to control this behavior

Reviewed Changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
web/src/utils/attachment.ts	Added logic to skip thumbnail requests for S3 images when setting is disabled
web/src/types/proto/api/v1/workspace_service.ts	Added TypeScript type definitions and serialization for the new setting
web/src/locales/en.json	Added English translation for the setting toggle label
web/src/components/Settings/MemoRelatedSettings.tsx	Added UI toggle for controlling S3 thumbnail generation
server/router/api/v1/workspace_service.go	Added field mapping between API and store representations
server/router/api/v1/attachment_service.go	Added server-side check to skip thumbnail generation for S3 images when disabled
proto/store/workspace_setting.proto	Added protobuf field definition for the store layer
proto/gen/store/workspace_setting.pb.go	Generated Go code for store protobuf
proto/gen/openapi.yaml	Updated OpenAPI specification with new field and formatting changes
proto/gen/api/v1/workspace_service.pb.go	Generated Go code for API protobuf
proto/gen/api/v1/user_service.pb.go	Removed extraneous empty comment line
proto/api/v1/workspace_service.proto	Added protobuf field definition for the API layer

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[FloDwld]

An alternative implementation would be to introduce a 3-way or 4-way setting (no thumbnails, on-the-fly, stored in S3) stored in the S3 configuration with the following semantics:

• no thumbnails: nothing special, would just require exposing that to users
• on-the-fly: current behavior to generate and cache a thumbnail locally when it is first requested
• stored in S3 only: generate a thumbnail whenever a new attachment is uploaded and store that in S3. The resource model (and the database) would need to be extended with a separate reference_thumb column that stores a pre-signed URL to the thumbnail image.
• (optional) stored in S3 for new uploads and on-the-fly for existing resources

This would be the cleanest change in my opinion, but is a larger rework and requires a database migration. What do you think?

[boojack]

An alternative implementation would be to introduce a 3-way or 4-way setting (no thumbnails, on-the-fly, stored in S3) stored in the S3 configuration with the following semantics:

• no thumbnails: nothing special, would just require exposing that to users
• on-the-fly: current behavior to generate and cache a thumbnail locally when it is first requested
• stored in S3 only: generate a thumbnail whenever a new attachment is uploaded and store that in S3. The resource model (and the database) would need to be extended with a separate reference_thumb column that stores a pre-signed URL to the thumbnail image.
• (optional) stored in S3 for new uploads and on-the-fly for existing resources

This would be the cleanest change in my opinion, but is a larger rework and requires a database migration. What do you think?

If just solving the issue of excessive memory usage, we can first just add a boolean field in WorkspaceStorageSetting, similar to the “enable thumbnail” option. When it’s enabled, we keep the current behavior (storing files locally).

[FloDwld]

I've refactored the pull request such that the setting is now located in the storage configuration. Note that the current value is reflected in the frontend attachment object, because no access to the storage configuration is possible for non-admin users.

[FloDwld]

I've rebased the pull request to the current main to fix merge conflicts.