has_one field doesn't show up

[manuelmeurer]

I added an has_one field to a resource and I want it to show up as a nested form when creating a new resource:

class Avo::Resources::Message < Avo::BaseResource
  def fields
    field :delivery, as: :has_one, nested: true
  end
end

The "delivery" field does not show up in the form, though.

This has happened before a few times with other fields, most of the time it was a problem with the policy.
I added a delivery_policy.rb though and it allows creating, updating etc.
I also use inherit_association_from_policy in my MessagePolicy to set create_delivery? etc. to true.
What else could be the problem?

EDIT: I have upgraded to the Professional plan to enable the nested form feature, and I have installed "avo-professional" instead of "avo-pro".

(in the future, it would be nice to have some kind of "debug mode" that could be turned on in development to find out why certain fields or actions are not displayed)

[Paul-Bob]

Hi @manuelmeurer

I have upgraded to the Professional plan to enable the nested form feature

Nested on forms is on the advanced license tier, it is also mentioned on the docs.

I would start by there, if I understand correctly you're using avo-pro instead of avo-advanced?

---

I have installed "avo-professional" instead of "avo-pro".

Did it work? Were you able to install avo-professional without any bundler errors?

---

in the future, it would be nice to have some kind of "debug mode" that could be turned on in development to find out why certain fields or actions are not displayed

We've discussed this a few times, and I agree it would be a really cool feature to have. It would greatly improve the DX (developer experience)! It's not on the near-term roadmap, but it's definitely something we want to support at some point.

[manuelmeurer]

Sorry, I keep mixing up the plans... 😅
I meant to say I upgraded from Pro to Advanced, and I installed avo-advanced instead of avo-pro.

[manuelmeurer]

I'm using v3.23.1 of all Avo gems.

The has_one association is polymorphic, maybe that is the issue?

class Delivery < ApplicationModel
  belongs_to :deliverable, polymorphic: true, inverse_of: :delivery
end

class Message < ApplicationModel
  has_one :delivery, as: :deliverable, inverse_of: :deliverable, dependent: :destroy
end

[Paul-Bob]

Yes, it's probably because of the polymorphic association.

I found this relevant thread, please read it and give it a try and let me know how it goes.

If you're still blocked please open a minimal reproduction repository so I can reproduce the issue.

Either way once we find the culprit we should investigate whether this can be supported natively in Avo or documented as a guide.

[manuelmeurer]

Ok, I dug a bit more through the Avo source and found out it has nothing to do with the association being polymorphic, I was really only missing an authorization method. 🤦‍♂️

class DeliveryPolicy
  def view_delivery? = true

  class Scope < Baseline::ApplicationPolicy::Scope
  end
end

Now the nested delivery fields show up (if I call @record.build_delivery in Avo::MessagesController#new).

My next problem is that all Delivery attributes are converted to {} before Avo assigns them to the record.
Example: I have a text field body:

field :body, as: :text

When I enter "test" and submit the form, Avo tries to assign {} to Delivery#body.
I think the problem is in avo-advanced (ResourceNestedHelper#create_new_nested_records). I can't really debug it properly, since I can't clone/fork avo-advanced to run with a local version.

EDIT: I can simply copy the version that Bundler installed to a new folder and reference that in my Gemfile. 😅

[Paul-Bob]

If the attributes for that model on params are just {}, my guess is that it probably has something to do with polymorphism

[manuelmeurer]

I think I found the line where {} is assigned, it doesn't seem to have anything to do with polymorphism.
Since it's in avo-advanced, I sent you further info via email.