activeadmin 2.2.0

data/docs/6-show-pages.md

@@ -0,0 +1,81 @@
+---
+redirect_from: /docs/6-show-pages.html
+---
+# Customize the Show Page
+
+The show block is rendered within the context of the view and uses
+[Arbre](https://github.com/activeadmin/arbre) syntax.
+
+With the `show` block, you can render anything you want.
+
+```ruby
+ActiveAdmin.register Post do
+  show do
+    h3 post.title
+    div do
+      simple_format post.body
+    end
+  end
+end
+```
+
+You can render a partial at any point:
+
+```ruby
+ActiveAdmin.register Post do
+  show do
+    # renders app/views/admin/posts/_some_partial.html.erb
+    render 'some_partial', { post: post }
+  end
+end
+```
+
+If you'd like to keep the default AA look, you can use `attributes_table`:
+
+```ruby
+ActiveAdmin.register Ad do
+  show do
+    attributes_table do
+      row :title
+      row :image do |ad|
+        image_tag ad.image.url
+      end
+    end
+    active_admin_comments
+  end
+end
+```
+
+You can also customize the title of the object in the show screen:
+
+```ruby
+show title: :name do
+  # ...
+end
+```
+
+If you want a more data-dense page, you can combine a sidebar:
+
+```ruby
+ActiveAdmin.register Book do
+  show do
+    panel "Table of Contents" do
+      table_for book.chapters do
+        column :number
+        column :title
+        column :page
+      end
+    end
+    active_admin_comments
+  end
+
+  sidebar "Details", only: :show do
+    attributes_table_for book do
+      row :title
+      row :author
+      row :publisher
+      row('Published?') { |b| status_tag b.published? }
+    end
+  end
+end
+```

data/docs/7-sidebars.md

@@ -0,0 +1,75 @@
+---
+redirect_from: /docs/7-sidebars.html
+---
+# Sidebar Sections
+
+Sidebars allow you to put whatever content you want on the side the page.
+
+```ruby
+sidebar :help do
+  "Need help? Email us at help@example.com"
+end
+```
+
+This will generate a sidebar on every page for that resource. The first
+argument is used as the title, and can be a symbol, string, or lambda.
+
+You can also use [Arbre](https://github.com/activeadmin/arbre) to define HTML content.
+
+```ruby
+sidebar :help do
+  ul do
+    li "Second List First Item"
+    li "Second List Second Item"
+  end
+end
+```
+
+Sidebars can be rendered on a specific action by passing `:only` or `:except`.
+
+```ruby
+sidebar :help, only: :index do
+  "Need help? Email us at help@example.com"
+end
+```
+
+If you want to conditionally display a sidebar section, use the :if option and
+pass it a proc which will be rendered within the view context.
+
+```ruby
+sidebar :help, if: proc{ current_admin_user.super_admin? } do
+  "Only for super admins!"
+end
+```
+
+You can access your model as resource in the sidebar too:
+
+```ruby
+sidebar :custom, only: :show do
+  resource.a_method
+end
+```
+
+You can also render a partial:
+
+```ruby
+sidebar :help                    # app/views/admin/posts/_help_sidebar.html.erb
+sidebar :help, partial: 'custom' # app/views/admin/posts/_custom.html.erb
+```
+
+It's possible to add custom class name to the sidebar parent element by passing
+`class` option:
+
+```ruby
+sidebar :help, class: 'custom_class'
+```
+
+By default sidebars are positioned in the same order as they defined, but it's also
+possible to specify their position manually:
+
+```ruby
+# will push Help section to the top (above default Filters section)
+sidebar :help, priority: 0
+```
+
+Default sidebar priority is `10`.

data/docs/8-custom-actions.md

@@ -0,0 +1,177 @@
+---
+redirect_from: /docs/8-custom-actions.html
+---
+
+# Custom Controller Actions
+
+Active Admin allows you to override and modify the underlying controller which
+is generated for you. There are helpers to add collection and member actions, or
+you can drop right in to the controller and modify its behavior.
+
+## Collection Actions
+
+A collection action is a controller action which operates on the collection of
+resources. This method adds both the action to the controller as well as
+generating a route for you.
+
+To add a collection action, use the collection_action method:
+
+```ruby
+ActiveAdmin.register Post do
+
+  collection_action :import_csv, method: :post do
+    # Do some CSV importing work here...
+    redirect_to collection_path, notice: "CSV imported successfully!"
+  end
+
+end
+```
+
+This collection action will generate a route at `/admin/posts/import_csv`
+pointing to the `Admin::PostsController#import_csv` controller action.
+
+## Member Actions
+
+A member action is a controller action which operates on a single resource.
+
+For example, to add a lock action to a user resource, you would do the
+following:
+
+```ruby
+ActiveAdmin.register User do
+
+  member_action :lock, method: :put do
+    resource.lock!
+    redirect_to resource_path, notice: "Locked!"
+  end
+
+end
+```
+
+This will generate a route at `/admin/users/:id/lock` pointing to the
+`Admin::UserController#lock` controller action.
+
+## HTTP Verbs
+
+The `collection_action` and `member_action` methods both accept the `:method`
+argument to set the HTTP verb for the controller action and route.
+
+Sometimes you want to create an action with the same name, that handles multiple
+HTTP verbs. In that case, this is the suggested approach:
+
+```ruby
+member_action :foo, method: [:get, :post] do
+  if request.post?
+    resource.update_attributes! foo: params[:foo] || {}
+    head :ok
+  else
+    render :foo
+  end
+end
+```
+
+## Rendering
+
+Custom controller actions support rendering within the standard Active Admin
+layout.
+
+```ruby
+ActiveAdmin.register Post do
+
+  # /admin/posts/:id/comments
+  member_action :comments do
+    @comments = resource.comments
+    # This will render app/views/admin/posts/comments.html.erb
+  end
+
+end
+```
+
+If you would like to use the same view syntax as the rest of Active Admin, you
+can use the Arbre file extension: .arb.
+
+For example, create `app/views/admin/posts/comments.html.arb` with:
+
+```ruby
+table_for assigns[:post].comments do
+  column :id
+  column :author
+  column :body do |comment|
+    simple_format comment.body
+  end
+end
+```
+
+## Page Titles
+
+The page title for the custom action will be the translated version of
+the controller action name. For example, a member_action named "upload_csv" will
+look up a translation key of `active_admin.upload_csv`. If none are found, it
+defaults to the name of the controller action.
+
+If this doesn't work for you, you can always set the `@page_title` instance
+variable in your controller action to customize the page title.
+
+```ruby
+ActiveAdmin.register Post do
+
+  member_action :comments do
+    @comments   = resource.comments
+    @page_title = "#{resource.title}: Comments" # Sets the page title
+  end
+
+end
+```
+
+# Action Items
+
+To include your own action items (like the New, Edit and Delete buttons), add an
+`action_item` block. The first parameter is just a name to identify the action,
+and is required. For example, to add a "View on site" button to view a blog
+post:
+
+```ruby
+action_item :view, only: :show do
+  link_to 'View on site', post_path(post) if post.published?
+end
+```
+
+Actions items also accept the `:if` option to conditionally display them:
+
+```ruby
+action_item :super_action,
+            only: :show,
+            if: proc{ current_admin_user.super_admin? } do
+  "Only display this to super admins on the show screen"
+end
+```
+
+By default action items are positioned in the same order as they defined (after default actions),
+but it’s also possible to specify their position manually:
+
+```ruby
+action_item :help, priority: 0 do
+  "Display this action to the first position"
+end
+```
+
+Default action item priority is 10.
+
+# Modifying the Controller
+
+The generated controller is available to you within the registration block by
+using the `controller` method.
+
+```ruby
+ActiveAdmin.register Post do
+
+  controller do
+    # This code is evaluated within the controller class
+
+    def define_a_method
+      # Instance method
+    end
+  end
+
+end
+```

data/docs/9-batch-actions.md

@@ -0,0 +1,237 @@
+---
+redirect_from: /docs/9-batch-actions.html
+---
+
+# Batch Actions
+
+By default, the index page provides you a "Batch Action" to quickly delete records,
+as well as an API for you to easily create your own. Note that if you override the
+default index, you must add `selectable_column` back for batch actions to be usable:
+
+```ruby
+index do
+  selectable_column
+  # ...
+end
+```
+
+## Creating your own
+
+Use the `batch_action` DSL method to create your own. It behaves just like a
+controller method, so you can send the client whatever data you like. Your block
+is passed an array of the record IDs that the user selected, so you can perform
+your desired batch action on all of them:
+
+```ruby
+ActiveAdmin.register Post do
+  batch_action :flag do |ids|
+    batch_action_collection.find(ids).each do |post|
+      post.flag! :hot
+    end
+    redirect_to collection_path, alert: "The posts have been flagged."
+  end
+end
+```
+
+### Disabling Batch Actions
+
+You can disable batch actions at the application, namespace, or resource level:
+
+```ruby
+# config/initializers/active_admin.rb
+ActiveAdmin.setup do |config|
+
+  # Application level:
+  config.batch_actions = false
+
+  # Namespace level:
+  config.namespace :admin do |admin|
+    admin.batch_actions = false
+  end
+end
+
+# app/admin/post.rb
+ActiveAdmin.register Post do
+
+  # Resource level:
+  config.batch_actions = false
+end
+```
+
+### Modification
+
+If you want, you can override the default batch action to do whatever you want:
+
+```ruby
+ActiveAdmin.register Post do
+  batch_action :destroy do |ids|
+    redirect_to collection_path, alert: "Didn't really delete these!"
+  end
+end
+```
+
+### Removal
+
+You can remove batch actions by simply passing false as the second parameter:
+
+```ruby
+ActiveAdmin.register Post do
+  batch_action :destroy, false
+end
+```
+
+### Conditional display
+
+You can control whether or not the batch action is available via the `:if`
+option, which is executed in the view context.
+
+```ruby
+ActiveAdmin.register Post do
+  batch_action :flag, if: proc{ can? :flag, Post } do |ids|
+    # ...
+  end
+end
+```
+
+### Priority in the drop-down menu
+
+You can change the order of batch actions through the `:priority` option:
+
+```ruby
+ActiveAdmin.register Post do
+  batch_action :destroy, priority: 1 do |ids|
+    # ...
+  end
+end
+```
+
+### Confirmation prompt
+
+You can pass a custom string to prompt the user with:
+
+```ruby
+ActiveAdmin.register Post do
+  batch_action :destroy, confirm: "Are you sure??" do |ids|
+    # ...
+  end
+end
+```
+
+### Batch Action forms
+
+If you want to capture input from the user as they perform a batch action,
+Active Admin has just the thing for you:
+
+```ruby
+batch_action :flag, form: {
+  type: %w[Offensive Spam Other],
+  reason: :text,
+  notes:  :textarea,
+  hide:   :checkbox,
+  date:   :datepicker
+} do |ids, inputs|
+  # inputs is a hash of all the form fields you requested
+  redirect_to collection_path, notice: [ids, inputs].to_s
+end
+```
+
+If you pass a nested array, it will behave just like Formtastic would, with the first
+element being the text displayed and the second element being the value.
+
+```ruby
+batch_action :doit, form: {user: [['Jake',2], ['Mary',3]]} do |ids, inputs|
+  User.find(inputs[:user])
+  # ...
+end
+```
+
+When you have dynamic form inputs you can pass a proc instead:
+
+```ruby
+batch_action :doit, form: -> { {user: User.pluck(:name, :id)} } do |ids, inputs|
+  User.find(inputs[:user])
+  # ...
+end
+```
+
+Under the covers this is powered by the JS `ActiveAdmin.modal_dialog` which you
+can use yourself:
+
+```coffee
+if $('body.admin_users').length
+  $('a[data-prompt]').click ->
+    ActiveAdmin.modal_dialog $(@).data('prompt'), comment: 'textarea',
+      (inputs)=>
+        $.post "/admin/users/#{$(@).data 'id'}/change_state",
+          comment: inputs.comment, state: $(@).data('state'),
+          success: ->
+            window.location.reload()
+```
+
+### Translation
+
+By default, the name of the batch action will be used to lookup a label for the
+menu. It will lookup in `active_admin.batch_actions.labels.#{your_batch_action}`.
+
+So this:
+
+```ruby
+ActiveAdmin.register Post do
+  batch_action :publish do |ids|
+    # ...
+  end
+end
+```
+
+Can be translated with:
+
+```yaml
+# config/locales/en.yml
+en:
+  active_admin:
+    batch_actions:
+      labels:
+        publish: "Publish"
+```
+
+### Support for other index types
+
+You can easily use `batch_action` in the other index views, *Grid*, *Block*,
+and *Blog*; however, these will require custom styling to fit your needs.
+
+```ruby
+ActiveAdmin.register Post do
+
+  # By default, the "Delete" batch action is provided
+
+  # Index as Grid
+  index as: :grid do |post|
+    resource_selection_cell post
+    h2 auto_link post
+  end
+
+  # Index as Blog requires nothing special
+
+  # Index as Block
+  index as: :block do |post|
+    div for: post do
+      resource_selection_cell post
+    end
+  end
+
+end
+```
+
+### BTW
+
+In order to perform the batch action, the entire *Table*, *Grid*, etc. is
+wrapped in a form that submits the IDs of the selected rows to your batch_action.
+
+Since nested `<form>` tags in HTML often results in unexpected behavior, you
+may need to modify the custom behavior you've built using to prevent conflicts.
+
+Specifically, if you are using HTTP methods like `PUT` or `PATCH` with a custom
+form on your index page this may result in your batch action being `PUT`ed
+instead of `POST`ed which will create a routing error. You can get around this
+by either moving the nested form to another page or using a POST so it doesn't
+override the batch action. As well, behavior may vary by browser.