• Home

  • Custom Ecommerce
  • Application Development
  • Database Consulting
  • Cloud Hosting
  • Systems Integration
  • Legacy Business Systems
  • Security & Compliance
  • GIS

  • Expertise

  • About Us
  • Our Team
  • Clients
  • Blog
  • Careers

  • CasePointer

  • VisionPort

  • Contact
  • Our Blog

    Ongoing observations by End Point Dev people

    Importing Data with RailsAdmin

    Steph Skardal

    By Steph Skardal
    January 19, 2012

    Update #1: Read an update to this functionality here.

    Update #2: This article was written in January of 2012, and the code related to the RailsAdmin actions no longer applies to the current release. Please make sure to read the RailsAdmin documentation regarding current action implementation.

    I’ve blogged about RailsAdmin a few times lately. I’ve now used it for several projects, and have included it as a based for the Admin interface my recent released Ruby on Rails Ecommerce Engine (Piggybak). One thing that I found lacking in RailsAdmin is the ability to import data. However, it has come up in the RailsAdmin Google Group and it may be examined in the future. One problem with developing import functionality is that it’s tightly coupled to the data and application logic, so building out generic import functionality may need more thought to allow for elegant extensibility.

    For a recent ecommerce project using RailsAdmin and Piggybak, I was required to build out import functionality. The client preferred this method to writing a simple migration to migrate their data from a legacy app to the new app, because this import functionality would be reusable in the future. Here are the steps that I went through to add Import functionality:

    #1: Create Controller

    class CustomAdminController < RailsAdmin::MainController
      def import
        # TODO
      end
    end
    

    First, I created a custom admin controller for my application in the app/controllers/ directory that inherits from RailsAdmin::MainController. This RailsAdmin controller has several before filters to set the required RailsAdmin variables, and defines the correct layout.

    #2: Add import route

    match "/admin/:model_name/import" => "custom_admin#import" , :as => "import", :via => [:get, :post]
    mount RailsAdmin::Engine => '/admin', :as => 'rails_admin'
    

    In my routes file, I introduced a new named route for import to point to the new custom controller. This action will be a get or a post.

    #3: Override Rails Admin View

    Next, I copied over the RailsAdmin app/views/rails_admin/_model_links.html.haml view to my application to override RailsAdmin’s view. I made the following addition to this file:

    ...
    - can_import = authorized? :import, abstract_model
    
    ...
    %li{:class => (params[:action] == 'import' && 'active')}= link_to "Import", main_app.import_path(model_name) if can_import
    

    With this logic, the Import tab shows only if the user has import access on the model. Note that the named route for the import must be prefixed with “main_app.”, because it belongs to the main application and not RailsAdmin.

    #4: CanCan Settings

    My application uses CanCan with RailsAdmin, so I leveraged CanCan to control which models are importable. The CanCan Ability class (app/models/ability.rb) was updated to contain the following, to allow exclude import on all models, and then allow import on several specific models.

    if user && user.is_admin?
      cannot :import, :all
      can :import, [Book, SomeModel1, SomeModel2, SomeModel3]
    end
    

    I now see an Import tab in the admin:

    #5: Create View

    Next, I created a view for displaying the import form. Here’s a generic example to display the set of fields that can be imported, and the form:

    <h1>Import</h1>
    <h2>Fields</h2>
    <ul>
        <% @abstract_model::IMPORT_FIELDS.each do |attr| -%>
        <li><%= attr %></li>
        <% end -%>
    </ul>
    
    <%= form_tag "/admin/#{@abstract_model.to_param}/import", :multipart => true do |f| -%>
        <%= file_field_tag :file %>
        <%= submit_tag "Upload", :disable_with => "Uploading..." %>
    <% end -%>
    

    This will look something like this:

    #6: Import Functionality

    Finally, the code for the import looks something like this:

    def import
      if request.post?
        response = { :errors => [], :success => [] }
        file = CSV.new(params[:file].tempfile)
    
        # Build map of attributes based on first row
        map {}
        file.readline.each_with_index { |key, i| map[key.to_sym] = i }
    
        file.each do |row|
          # Build hash of attributes
          new_attrs = @abstract_model.model::IMPORT_FIELDS.inject({}) { |hash, a| hash[a] = row[map[a]] if map[a] }
    
          # Instantiate object
          object = @abstract_model.model.new(new_attrs)
    
          # Additional special stuff here
    
          # Save
          if object.save
            response[:success] << "Created: #{object.title}"
          else
            response[:error] << "Failed to create: #{object.title}. Errors: #{object.errors.full_messages.join(', ')}."
          end
        end
      end
    end
    

    Note that a hash of keys and locations is created to map keys to the columns in the imported file. This allows for flexibility in column ordering of imported files. Later, I’d like to to re-examine the CSV documentation to identify if there is a more elegant way to handle this.

    #7: View updates to show errors

    Finally, I update my view to show both success and error messages, which looks sorta like this in the view:

    Conclusion and Discussion

    It was pretty straightforward to get this figured out. The only disadvantage I see to this method is that overriding the rails_admin view requires recopying or manual updates to the view over during upgrades of the gem. For example, if any part of the rails_admin view has changes, those changes must also be applied to the custom view. Everything else should be smooth sailing :)

    In reality, my application has several additional complexities, which make it less suitable for generic application:

    • Several of the models include attached files via paperclip. Using open-uri, these files are retrieved and added to the objects.
    • Several of the models include relationships to existing models. The import functionality requires lookup of these associated models (e.g. an imported book belongs_to an existing author), and reports and error if the associated objects can not be found.
    • Several of the models require creation of a special nested object. This was model specific.
    • Because of this model specific behavior, the import method is moved out of the controller into model-specific class methods. For example, CompactDisc.import is different from Book.import which is different from Track.import. Pulling the import into a class method also makes for a skinnier controller here.

    ecommerce ruby rails


    Comments