Support for virtual fields (regression)

[pablobm]

When #920 was merged, it broke apps that depended on the old behaviour.

These are two reports on this issue:

Report by @wkirby in #920 (comment)

This PR appears to break any support for virtual fields by enforcing the the resource must define a method to respond to all keys in the Dashboard class. Maybe this is the desired behavior, but the following use case was possible in 0.12.0, and was very useful:

class ReportDashboard < Administrate::BaseDashboard
  ATTRIBUTE_TYPES = {
    id: Field::Number,
    filename: Field::String,
    mimetype: Field::String,
    s3_key: Field::String,
    download: S3DownloadField.with_options({ download_path: :download_lab_report_path }),
    page_count: Field::Number,
    created_at: Field::DateTime,
    updated_at: Field::DateTime
  }.freeze

  COLLECTION_ATTRIBUTES = [
    :id,
    :filename,
    :download,
    :mimetype,
    :created_at
  ].freeze

  SHOW_PAGE_ATTRIBUTES = [
    :id,
    :download,
    :filename,
    :mimetype,
    :s3_key,
    :page_count,
    :created_at,
    :updated_at
  ].freeze

  FORM_ATTRIBUTES = [
    :lab,
    :filename,
    :mimetype,
    :s3_key,
    :page_count
  ].freeze
end

class S3DownloadField < Administrate::Field::Base
  def to_s
    data
  end

  def downloadable?
    options.key?(:download_path)
  end

  def destroyable?
    options.key?(:destroy_path)
  end

  def destroy_path(field, attachment)
    path_helper(:destroy_path, field, attachment)
  end

  def download_path(field, attachment)
    path_helper(:download_path, field, attachment)
  end

  private

  def path_helper(key, field, _attachment)
    path_helper = options.fetch(key)
    Rails.application.routes.url_helpers.send(path_helper, field.resource)
  end
end

This allowed us to inject a download link for our S3 resource without editing the underlying views, or modifying the display for any of the actual attributes.

Is there any advice on how to fix this without defining useless methods on our models?

Report by @Timmitry in #1570 (comment)

We are having similar problems - updating to 0.13 breaks all of our virtual fields (and we have many of those). Since 0.13 fixes a CVE, this is kind of an urgent problem 😕

We fixed the issue temporarily by adding an initializer to config/initializers with the following code:

# Monkey patch to make the … page work again
# The breaking change was https://github.com/thoughtbot/administrate/commit/dc856a917aa67e998860bb42664b5da94eb0e682#diff-a4a632998186059ef606368d710ac173
# Issue is open at https://github.com/thoughtbot/administrate/issues/1570
raise "Try to remove this monkey patch when updating Administrate" if Gem.loaded_specs["administrate"].version != Gem::Version.new("0.13.0")

module Administrate
  module Page
    class Base
      protected

      def get_attribute_value(resource, attribute_name)
        resource.public_send(attribute_name)
      rescue NameError
        nil
      end
    end
  end
end

[sedubois]

A bit related to this, Jumpstart Rails runs a fork of Administrate with this extra commit:
excid3@ac3b8b8

Maybe such a patch would enable the described scenario?

[pablobm]

The thing with that patch is that it is for a generator, rather than for code that runs day-to-day. Do they have anything else?

[sedubois]

Not that I’m aware of.

[pablobm]

Then I'm not sure that the linked commit fixes the problem. Instead, it appears to add detection of virtual attributes added with attribute. Also, this is not the only way to have virtual attributes; it can be done with just instance methods.

[wvengen]

It looks like getting the value from the resource in Administrate::Base::Page#attribute_field is a culprit:

administrate/lib/administrate/page/base.rb

Lines 28 to 36 in 844c270

	def attribute_field(dashboard, resource, attribute_name, page)
	value = get_attribute_value(resource, attribute_name)
	field = dashboard.attribute_type_for(attribute_name)
	field.new(attribute_name, value, page, resource: resource)
	end
	def get_attribute_value(resource, attribute_name)
	resource.public_send(attribute_name)
	end

I can think of some solutions (but I guess there would be more):

• Let the field get the value from the resource. This would allow custom fields to use their own method to get the value, and only call it when necessary. This may break the field api, though (but not for inputs using the input base class constructor - which I think would be most). (I think this could fix download in the example above.)
• Add a virtual option to all fields, which expects a boolean argument. If it is true, the value would just be nil.
• Add a general value (or getter) option to all fields, which expects a proc/... to get the value (defaulting to line 29 above).
  And perhaps when this option is nil, don't prefill a value at all (that could fix download in the example above)

I guess the last would be the most flexible - but it may lead to other wishes (perhaps a custom value-setter option).

---

I'm actually having a slightly different use-case for virtual fields: combining several model attributes in a single element using a custom field type (for me that's year and week of a publication that is always entered together, and it has a better user- experience to treat it as a single element).

[pablobm]

Thanks to all who helped explain this issue!

@wkirby, @Timmitry - For the moment, a workaround might be to add a method of this name (in your example download) to the model. For example, just this empty method fixes the issue when I reproduce it in my setup:

def download
end

Can people confirm is this is enough for them while we get to a better solution (which admittedly will still take time)?

[pablobm]

@wvengen - Thank you for looking into this :-) Initially, I'm more inclined towards the first option. I have seen other use cases where having the field decide its value by looking at the whole resource would be useful, and this is exactly a case of that.

You are right that it would break the Fields API, so I would want this to happen in an ordered fashion that allowed for initial back-compatibility while plugins and users adapt, first showing warnings for a few versions, then dropping it altogether.

Only since recently, the whole resource is given to the field, so that's a start. What I'm not sure of is how we would phase out the second argument (data) and raise warnings, etc, so that people are made aware of the change without breaking their apps at first.

Any ideas? I'd welcome a PR if you have the time. A tentative PR to explore the solution would be great, so that there's no pressure to get it right first time, and we can evaluate solutions before committing to one.

[wvengen]

Thanks for your response, @pablobm. We're still evaluating the use of Administrate (coming from Brightcontent). If we go for it, we'll probably have a go at a PR (but it'll take some time).