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

Request for expanded documentation for Configuring fields #963

Closed
JohnGoodman opened this issue Feb 6, 2012 · 4 comments
Closed

Request for expanded documentation for Configuring fields #963

JohnGoodman opened this issue Feb 6, 2012 · 4 comments

Comments

@JohnGoodman
Copy link

Hey,

I've been using the Configuring fields section of the Railsadmin DSL article to get my project setup. The documentation says I can use configure just like I use field. However, whenever I use configure, rails_admins seems to ignore it. I'm not sure if my syntax is wrong or if rails_admin has an issue in this area. Further documentation would help clarify for people. See my code below for whats working and not working.

Rails 3.1.3
Ruby 1.9.3

This code works. It sets the user id to the current user and hides the field. Additionally, it shows the name and description field.

config.model Post do
  edit do
    field :name
    field :description
    field :user_id, :hidden do
      help ""
      default_value do
        bindings[:view]._current_user.id
      end
    end
  end
end

This does nothing. All fields show like there is no configuration set:

config.model Post do
  edit do
    configure :user_id, :hidden do
      help ""
      default_value do
        bindings[:view]._current_user.id
      end
    end
  end
end

Thank you.

@JohnGoodman
Copy link
Author

Ok, I worked with this some more and have found something kinda funky. I can configure a model to have a default value for the user_id field and show all other fields automatically. However, the syntax is pretty counter-intuitive. I had to add a block for 'user' as well as 'user_id' in order for everything to work correctly. Submitting a 'user' with a value of 2 breaks rails, so I then had to exclude the user field.

config.model Post do
  edit do
    field :user_id, :hidden do
      help ""
      default_value do
        bindings[:view]._current_user.id
      end
    end

    field :user, :hidden do
      help ""
      default_value do
        bindings[:view]._current_user.id
      end
    end

    include_all_fields
    exclude_fields :user
  end
end

Thanks

@bbenezech
Copy link
Collaborator

The belongs_to association is named :user
:user_id is the column used by this association.

RailsAdmin hides :user_id when creating the :user belongs_to association.

So when you configure :user_id, you actually are configuring a field that is not outputed in the form.

the configure verb of the DSL does not modify the visibility. On the contrary, field shows the field if it was hidden at initialization.

Another issue is that default_value is implemented in the form views and currently filtering_select does not take it into account. Pull request welcome.

What you can do is hide the association and 'show' the :user_id column as a hidden field when creating the parent object:

create do
  configure :user do
    visible false
  end

  configure :user_id, :hidden do
    visible true
    default_value do
      bindings[:view]._current_user.id
    end
  end
end

Feel free to update the wiki at will, of course.

@JohnGoodman
Copy link
Author

Thanks for the quick response. I updated https://github.com/sferik/rails_admin/wiki/How-to-set-default-values to hopefully help someone out. Feel free to edit what I wrote as needed.

@brookr
Copy link

brookr commented Sep 16, 2012

This seems to work even better if I just work with :user directly. Here's an example from my code, working with a Rating model that belongs_to :user:

edit do
  field :stars
  field :comment
  field :user do
    default_value do
      bindings[:view]._current_user
    end
  end
end

I don't seem to need the initial configure block with the visible setting. And it displays user names, rather than user id numbers, which are a lot harder to work with.

Am I missing something doing it this way? or does the example given simply work better if you don't want user assignment shown in the form?

If that's the case, I'll edit the wiki to leave a comment for people who do want to see the user value that's getting set.

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