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

How to type an attribute that returns a model but doesn't use a has_one association #2546

Open
mpvosseller opened this issue Mar 11, 2024 · 2 comments

Comments

@mpvosseller
Copy link

My Foo model has a method called bar that returns a Bar model instance (or nil).

It is technically not a has_one association though because there is not foreign key. Rather the bar method uses some business logic to determine which Bar to return.

In the Foo dashboard, what "type" should I use for the bar attribute?

I found that I can use the "Field::HasOne" with the class_name option but that option is deprecated:

  bar: Field::HasOne.with_options(class_name: "Bar"),

If I omit the class_name option Administrate crashes because (I think) it can't determine the type via reflection.

  bar: Field::HasOne,

Thanks.

@nickcharlton
Copy link
Member

I'm not really sure what a good suggestion for this might be, aside from writing a custom field (which, perhaps is too much in this case?).

I will note #2384, though, where we've found other cases where class_name is necessary.

@pablobm
Copy link
Collaborator

pablobm commented Oct 26, 2024

A custom field is probably a good option, particularly since #2658

However, I think it's reasonable to do with a HasOne too 🤔

nickcharlton pushed a commit to pablobm/administrate that referenced this issue Nov 4, 2024
We tried to remove `:class_name` (along with some others), as it didn't
seem like they had a legitimate use as of thoughtbot#2384 and thoughtbot#2546. But we've
been seeing various cases where it's still helpful to have.

Closes thoughtbot#2384.
nickcharlton pushed a commit that referenced this issue Nov 4, 2024
We tried to remove `:class_name` (along with some others), as it didn't
seem like they had a legitimate use as of #2384 and #2546. But we've
been seeing various cases where it's still helpful to have.

Closes #2384.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants