Bump @cap-js/attachments from 2.0.2 to 3.5.0

[dependabot]

Bumps @cap-js/attachments from 2.0.2 to 3.5.0.

Release notes

Sourced from @​cap-js/attachments's releases.

v3.5.0

Fixed

• Enforced the use of the Content-Length header to prevent server errors.
• Designated the content property in the Attachments table as a NonSortableProperty to prevent database errors when sorting LargeBinary fields.

v3.4.0

Added

• Introduced support for the @Core.AcceptableMediaTypes annotation, allowing specification of permitted MIME types for attachment uploads:

  annotate my.Books.attachments with {
      content @Core.AcceptableMediaTypes: ['image/jpeg'];
  }

• Added support for the @Validation.Maximum annotation to define the maximum allowed file size for attachments:

  annotate my.Books.attachments with {
      content @Validation.Maximum: '2MB';
  }

Fixed

• Removed the previous hard limit of 400 MB for file uploads. Files exceeding this size may still fail during malware scanning and will be marked with a Failed status.
• Resolved issues with generic handler registration, enabling services to intercept the attachments plugin using middleware.

v3.3.0

Added

• Added standard kind and set it as the default so that the configuration needs no adjustment when switching hyper-scalers.
• Added support for uploading and updating attachments via srv.run(INSERT.into(Attachments).entries()) or srv.run(UPDATE.entity(Attachments).set())

Fixed

• Fixed an issue that in multi-tenancy scenarios with separate object stores duplicate object stores per tenant were created when updating the tenant binding via the SaaS dependency service.
• Fixed a race-condition where tenant isolation in separate object store mode could be broken.
• Fixed a case where attachments were not correctly deleted.
• Fixed a server crash when using the AttachmentsSrv.put API to upload an attachment.
• Fixed a server crash when no object store would be bound to the application on BTP.
• Fixed a server crash when the filename would not be given when creating new attachment metadata.
• Fixed an issue where attachment handlers would be missing when all Attachments entity were behind feature toggles.
• Fixed an issue where with storage kind db attachments could not be uploaded as drafts.
• Fixed an issue where the content could be uploaded for a not existing attachments entity.

v3.2.0

Added

• Implemented integration with additional cloud providers for attachment storage:
  • Azure Blob Storage (kind: azure).

... (truncated)

Changelog

Sourced from @​cap-js/attachments's changelog.

Version 3.5.0

Fixed

• Enforced the use of the Content-Length header to prevent server errors.
• Designated the content property in the Attachments table as a NonSortableProperty to prevent database errors when sorting LargeBinary fields.

Version 3.4.0

Added

• Introduced support for the @Core.AcceptableMediaTypes annotation, allowing specification of permitted MIME types for attachment uploads:

  annotate my.Books.attachments with {
      content @Core.AcceptableMediaTypes: ['image/jpeg'];
  }

• Added support for the @Validation.Maximum annotation to define the maximum allowed file size for attachments:

  annotate my.Books.attachments with {
      content @Validation.Maximum: '2MB';
  }

Fixed

• Removed the previous hard limit of 400 MB for file uploads. Files exceeding this size may still fail during malware scanning and will be marked with a Failed status.
• Resolved issues with generic handler registration, enabling services to intercept the attachments plugin using middleware.

Version 3.3.0

Added

• Added standard kind and set it as the default so that the configuration needs no adjustment when switching hyper-scalers.
• Added support for uploading and updating attachments via srv.run(INSERT.into(Attachments).entries()) or srv.run(UPDATE.entity(Attachments).set())

Fixed

• Fixed an issue that in multi-tenancy scenarios with separate object stores duplicate object stores per tenant were created when updating the tenant binding via the SaaS dependency service.
• Fixed a race-condition where tenant isolation in separate object store mode could be broken.
• Fixed a case where attachments were not correctly deleted.
• Fixed a server crash when using the AttachmentsSrv.put API to upload an attachment.
• Fixed a server crash when no object store would be bound to the application on BTP.
• Fixed a server crash when the filename would not be given when creating new attachment metadata.
• Fixed an issue where attachment handlers would be missing when all Attachments entity were behind feature toggles.
• Fixed an issue where with storage kind db attachments could not be uploaded as drafts.
• Fixed an issue where the content could be uploaded for a not existing attachments entity.

Version 3.2.0

... (truncated)

Commits

• df1419f Update CHANGELOG for version 3.5.0: document fixes for Content-Length… (#322)
• 1f5384d EnforceContent-Length header and add corresponding error handling (#321)
• 8de1b70 Consistently provider target for delete (#320)
• d79c94e Refactor attachment definitions for improved readability and consistency (#318)
• f6ede42 Implement mime type validation for attachments and enhance error hand… (#316)
• f265c31 Leverage generic handler registration (#309)
• 39ea186 Changelog for 3.3 (#307)
• 372913f Attempting to PUT into non-existent entity should return 404 (#299)
• ed23cf5 Remove log wrapper and move services into srv folder (#306)
• 0d1fadb Fix separate object store race condition and add standard plan (#303)
• Additional commits viewable in compare view

Maintainer changes

This version was pushed to npm by [GitHub Actions](https://www.npmjs.com/~GitHub Actions), a new releaser for @​cap-js/attachments since your current version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)