I think I’m okay with recognizing a special value so that you can more
easily delete an attachment via a form, but given that we can choose any
value, I’d prefer something other than an empty string (like "delete" or {
"delete" => true }).
On Mon, Jul 16, 2018 at 12:33 AM Kyle Fox <kyle....@gmail.com> wrote:
> Sorry, I should've been more specific in my initial post:
>
> - I'm proposing this change *only* for has_one_attachment i.e. the
> ability to use user.update! image: "" in place of user.image.detach
> - When comparing the behavior to has_many_attached, I mean in the
> sense that has_many_attached detaches attachments when assigned a
> blank value (nil or []), i.e. user.update! highlights: nil
>
> What would we do in the following cases? Ignore the empty strings?
>
>
>> user.update! highlights: [ "" ]
>> user.update! highlights: [ "eyJfcmF--e31aef3", "" ]
>
>
> You're right — in these cases it's not clear what should happen.
>
> Currently the empty strings would raise the InvalidSignature error. I
> suppose it would behave like this, if blank strings were treated as
> "detachments" / discarded?
>
> - user.update! highlights: [ "" ] would effectively detach all
> highlights
> - user.update! highlights: [ "eyJfcmF--e31aef3", "" ] would attach a
> single blob in the collection, i.e. user.highlights.length == 1
>
>
> Kyle.
>
> On Sunday, July 15, 2018 at 10:10:37 PM UTC-6, geo...@basecamp.com wrote:
>>
>> To be clear, the writer method added by has_many_attached does not
>> already accept empty strings.
>>
>> What would we do in the following cases? Ignore the empty strings?
>>
>> user.update! highlights: [ "" ]
>> user.update! highlights: [ "eyJfcmF--e31aef3", "" ]
>>
>> George
>>
>> On Sunday, July 15, 2018 at 11:41:05 PM UTC-4, Kyle Fox wrote:
>>>
>>> ActiveStorage allows attachments to be attached by assigning a string
>>> representing a blob's signed_id. This works _brilliantly_ because it
>>> enables the same params conventions used when assigning other attributes
>>> through forms → controllers → models:
>>>
>>> params = { user: { image: 'eyJfcmF--e31aef3' } }
>>>
>>> However, it's surprising that setting the attachment to an empty string
>>> does _not_ detach the attachment:
>>>
>>> params = { user: { image: '' } } # => InvalidSignature
>>>
>>> It feels more Railsy to treat the empty string as a special case that
>>> detaches the attachment.
>>>
>>> This would allow attachments to be removed in a way that mirrors how
>>> they are added (i.e. posting hidden field values) instead of having to call
>>> @user.image.detach in a controller. For example, this would handle both
>>> attaching and detaching @user.image:
>>>
>>> @user.update_attributes(params.require(:user).permit(:name, :email,
>>> :image))
>>>
>>> Ideally in this scenario, if params[:user][:image] was '' ActiveStorage
>>> would call @user.image.detach.
>>>
>>> Currently if you assign an empty string to an attachment an
>>> ActiveSupport::MessageVerifier::InvalidSignature error is raised.
>>>
>>> Apparently
>>> <https://github.com/rails/rails/issues/33362#issuecomment-405080017>
>>> this is already how has_many_attached behaves — it'd be nice if
>>> has_one_attached behaved similarly.
>>>
>>> Any interest in this functionality? If so I'd be happy to put together a
>>> patch. 👍
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at https://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
