Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preserve existing attachment assignment behavior for upgraded apps #36716

Merged
merged 1 commit into from
Jul 20, 2019

Conversation

georgeclaghorn
Copy link
Contributor

@georgeclaghorn georgeclaghorn commented Jul 19, 2019

Assigning a collection of attachments appends to the collection as it did in 5.2. Existing 5.2 apps that rely on this behavior will no longer break when they're upgraded to 6.0.

For apps generated on 6.0 or newer, assigning replaces the existing attachments in the collection. #attach should be used to add new attachments to the collection without removing existing ones.

I expect that we'll deprecate the old behavior in 6.1.

Closes #36374.

To-do:

  • Tests
  • Changelog and documentation updates
  • Review

@georgeclaghorn georgeclaghorn force-pushed the ast-assignment-backcompat branch 3 times, most recently from 5321642 to 1cd1477 Compare July 19, 2019 21:36
@rails-bot rails-bot bot added the docs label Jul 19, 2019
@georgeclaghorn georgeclaghorn force-pushed the ast-assignment-backcompat branch 2 times, most recently from 8d239c3 to ce31f2d Compare July 20, 2019 00:47
Assigning to a collection of attachments appends rather than replacing, as in 5.2. Existing 5.2 apps that rely on this behavior will no longer break when they're upgraded to 6.0.

For apps generated on 6.0 or newer, assigning replaces the existing attachments in the collection. #attach should be used to add new attachments to the collection without removing existing ones.

I expect that we'll deprecate the old behavior in 6.1.

Closes #36374.
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Dec 14, 2021
The background
---

Configuration for replacing a collection was introduced in
[rails#36716][].

However, since [rails#42596][] has been merged, Rails 7.1 and
beyond will default to _replacing_ an Active Storage `has_many_attached`
relationship, as opposed to _appending to it_.

The problem
---

With replacement as the established precedent, it's currently a
challenge to replace an existing collection with an empty one.

The solution
---

This commit makes two changes.

The first is to Action View and its form building helpers. The change
draws inspiration from how an `<input type="checkbox">` field (or
collection of fields) is paired with an `<input type="hidden">` field to
represent the unchecked value. The change pairs any `<input type="file"
multiple="multiple">` elements with an `<input type="hidden">` element
to represent an empty collection. Like the [check_box][] form builder
method, the `file_field`  method accepts an `include_hidden:` option to
skip the creation of the hidden element.

The second is to how Active Storage generates attribute assignment
methods through `has_many_attached`. With the possibility of an `<input
type="file">` field being paired with an `<input type="hidden"
value="">` field, the backing models need to be able to coerce an
"empty-ish" value into an empty list. For example:

```ruby
@user.highlights = [""]
@user.highlights        # => []
```

When combined, these changes enable consumer applications to submit
"empty" collections to blank out existing attachments.

Support is configured through the
`config.active_storage.multiple_file_field_include_hidden` configuration
value, which defaults to `false`.

[check_box]: https://edgeapi.rubyonrails.org/classes/ActionView/Helpers/FormBuilder.html#method-i-check_box
[rails#36716]: rails#36716
[rails#42596]: rails#42596
jyoun-godaddy pushed a commit to jyoun-godaddy/activestorage that referenced this pull request Jul 5, 2022
The background
---

Configuration for replacing a collection was introduced in
[rails/rails#36716][].

However, since [rails/rails#42596][] has been merged, Rails 7.1 and
beyond will default to _replacing_ an Active Storage `has_many_attached`
relationship, as opposed to _appending to it_.

The problem
---

With replacement as the established precedent, it's currently a
challenge to replace an existing collection with an empty one.

The solution
---

This commit makes two changes.

The first is to Action View and its form building helpers. The change
draws inspiration from how an `<input type="checkbox">` field (or
collection of fields) is paired with an `<input type="hidden">` field to
represent the unchecked value. The change pairs any `<input type="file"
multiple="multiple">` elements with an `<input type="hidden">` element
to represent an empty collection. Like the [check_box][] form builder
method, the `file_field`  method accepts an `include_hidden:` option to
skip the creation of the hidden element.

The second is to how Active Storage generates attribute assignment
methods through `has_many_attached`. With the possibility of an `<input
type="file">` field being paired with an `<input type="hidden"
value="">` field, the backing models need to be able to coerce an
"empty-ish" value into an empty list. For example:

```ruby
@user.highlights = [""]
@user.highlights        # => []
```

When combined, these changes enable consumer applications to submit
"empty" collections to blank out existing attachments.

Support is configured through the
`config.active_storage.multiple_file_field_include_hidden` configuration
value, which defaults to `false`.

[check_box]: https://edgeapi.rubyonrails.org/classes/ActionView/Helpers/FormBuilder.html#method-i-check_box
[rails/rails#36716]: rails/rails#36716
[rails/rails#42596]: rails/rails#42596
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Active Storage has_many_attached attachments get destroyed when subsequent files are attached
2 participants