Fields feedback

[adrianthedev]

Let's use this space to provide feedback for anything field-related.

Post an issue if something is broken.

[Sandilly]

Hi, I am trying to create a field that will automatically generate a default value off another form field input value. Does the default block have access to other form values on create (values that have not been saved to the record)?

[adrianthedev]

You can do that using the StimulusJS integration.
You'll need to write a controller that watches for changes and updates the field.

Docs with demo video:
https://docs.avohq.io/3.0/stimulus-integration.html

Live demo:
https://avodemo.com/avo/resources/courses/147/edit

The code:
https://github.com/avo-hq/main.avodemo.com/blob/main/app/javascript/controllers/course_controller.js

[Sandilly]

Thank you for your guidance. I will try this.

[manuelmeurer]

I added a field and it doesn't show up in the index or show view:

class Avo::Resources::Talk < Avo::BaseResource
  def fields
    field :speakers, as: :has_many
  end
end

This is my model:

class Talk < ApplicationRecord
  has_many :talk_speakers
  has_many :speakers, through: :talk_speakers, source: :user
end

Question 1: what do I have to do to make it show up in the show view (not the index view)?
Question 2: if i misconfigured something, why does the field simply not show up instead of raising an error? It's super frustrating to not get any feedback from the system about what might be wrong.

[manuelmeurer]

Adding view_speakers? to the talk policy solved this:

class TalkPolicy < ApplicationPolicy
  def view_speakers? = true

  class Scope < ApplicationPolicy::Scope
  end
end

Probably an error should be raised if the resource has a :has_many field and the policy does not have a view_resources? method?

[manuelmeurer]

Another question: my Talk model has a JSON field named "tracks" that contains an array of strings. I'd like to show this field, either as a list with bullets or comma joined, for each talk in the show and index views. How can I do this?
I added field :tracks, as: :array to the resource, but again, the field doesn't show up anywhere. No warning or error in the logs either.

[Paul-Bob]

Probably an error should be raised if the resource has a :has_many field and the policy does not have a view_resources? method?

We’re considering adding notifications to give developers an overview of what is being unauthorized when the page loads.

---

I added field :tracks, as: :array to the resource, but again, the field doesn't show up anywhere. No warning or error in the logs either.

Got it! Array fields and array resources are currently in beta. Simply adding field :tracks, as: :array won’t work out of the box. You need to define a dedicated resource for tracks and specify which fields should be displayed within that resource. You can find more details in the documentation.

Even if you have already created the resource, the field still might not appear. The underlying issue is that array fields inherit most behaviors from has_many fields. As a result, you need to explicitly allow viewing by adding def view_tracks? = true to your policy.

This requirement isn’t currently documented, but I’ll make sure we update the docs to mention it. Thanks for bringing this up, it helps improve the beta phase of array fields!

---

Another question: my Talk model has a JSON field named "tracks" that contains an array of strings. I'd like to show this field, either as a list with bullets or comma joined, for each talk in the show and index views. How can I do this?

Since you want to display an array of values in the index and show views, I recommend using the tags field type. This will automatically process the array and display each item as a tag.

# app/models/talk.rb
class Talk < ApplicationRecord
  def tracks
    ["one", "two", "three"]
  end
end

# app/avo/resources/talk.rb
class Avo::Resources::Talk < Avo::BaseResource
  def fields
    # only on the show and index pages
    field :tracks, as: :tags, only_on: :display
  end
end

This should render the tracks values as styled tags, making them more visually appealing and readable.

This is just one approach, feel free to explore other solutions and let us know how it works for you! You can also create a custom field if you need greater flexibility over the design and behavior of the tracks section. Custom fields let you fine-tune the presentation to better fit your specific requirements.

[manuelmeurer]

The "tags" field type is exactly what I was looking for, thanks! :)

[Paul-Bob]

Awesome! I'm glad it worked out for your use-case.

Anytime! Thanks for all the feedback!

[manuelmeurer]

Here's another issue where I'm a bit stumped that it doesn't work, and there's no error message and no log output.
I'm trying to add a dynamic filter to a field.

class Avo::Resources::Ticket < Avo::BaseResource
  def fields
    field :item_name, as: :select, options: -> { record.item_names }, filterable: true
  end
end

class Ticket < ApplicationRecord
  def self.ransackable_attributes(auth_object = nil) = %w(item_name)
  def item_names
    raise
  end
end

The "Filters" button does not appear and nothing is raised, i.e. the Ticket#item_names method is never called.
What am I doing wrong?

[manuelmeurer]

I'm on Avo Pro 3.17.9, in case that makes a difference.

[Paul-Bob]

Hi @manuelmeurer

I'm on Avo Pro 3.17.9, in case that makes a difference.

Dynamic filters are included on the Advanced plan that's why filterable option takes no effect on Pro or Community plan.

Thank you for the feedback!

[manuelmeurer]

Oh, that's disappointing. I think "dynamic filters" should be the default, I needed those in every admin CMS I ever worked with.
Also, if a user on the community or pro plan uses the parameter, I would expect a warning about it in the UI or logs.

[adrianthedev]

Hey Manuel, this is Adrian, the author of Avo.

I understand. I really do. I use filters in most of my apps as well. That's why we have the basic filters in the Community tier for free.

The Dynamic Filters are incredibly powerful and enable developers to create a richer experience for their users. Also it requires a higher level of support form us to capture all the corner cases. That's the reason why they are in the Advanced tier.

@Paul-Bob has created an issue to add more warnings for paid features.

THanks for the feedback ✌️

[manuelmeurer]

Thanks for your reply, @adrianthedev! I respectfully disagree, since I don't think a feature that pretty much every CMS needs at some point should be in the $150/month price range, but hey, in the end it's your decision. 😄
I still get a lot of value out of the Pro version of Avo.