invites.rb

[geekelo]

FILE

ActiveAdmin.register Invite do

  actions :all, except: [:new, :edit, :destroy]

  config.sort_order = 'created_at_asc'

  menu parent: 'Users', label: 'User Invites'

  # See permitted parameters documentation:
  # https://github.com/activeadmin/activeadmin/blob/master/docs/2-resource-customization.md#setting-up-strong-parameters
  #
  # Uncomment all parameters which should be permitted for assignment
  #
  # permit_params :user_id, :email, :name, :message, :include_referral_link, :invited_at, :status, :discarded_at
  #
  # or
  #
  # permit_params do
  #   permitted = [:user_id, :email, :name, :message, :include_referral_link, :invited_at, :status, :discarded_at]
  #   permitted << :other if params[:action] == 'create' && current_user.admin?
  #   permitted
  # end

end

[geekelo]

This ActiveAdmin configuration is set up to manage Invite records within the admin interface. Here’s a detailed breakdown of its components:

1. Actions Configuration

• actions :all, except: [:new, :edit, :destroy]:
  This line specifies which actions are available for the Invite resource. The :new, :edit, and :destroy actions are excluded, meaning administrators can only view the list of invites and their details (index and show actions). This setup is likely in place because invites may be automatically generated or managed outside the typical CRUD (Create, Read, Update, Delete) operations.

2. Sort Order Configuration

• config.sort_order = 'created_at_asc':
  This sets the default sort order for Invite records to be by created_at in ascending order. The oldest invites will appear first, which can help administrators review invites in the order they were sent.

3. Menu Configuration

• menu parent: 'Users', label: 'User Invites':
  This line places the Invite resource under the "Users" menu in the ActiveAdmin interface, with the label "User Invites." This categorization indicates that the invites are directly related to user management, possibly for inviting new users to the platform.

4. Permitted Parameters

• permit_params:
  The permit_params block is commented out, meaning that no parameters are currently permitted for assignment through the admin interface. If uncommented and configured, it would allow administrators to specify which attributes of an Invite record can be modified.

  The potential parameters include:

  • user_id: The ID of the user who sent the invite.
  • email: The email address of the person being invited.
  • name: The name of the person being invited.
  • message: A custom message included with the invite.
  • include_referral_link: A boolean indicating whether a referral link is included.
  • invited_at: The timestamp when the invite was sent.
  • status: The current status of the invite (e.g., sent, accepted, pending).
  • discarded_at: The timestamp when the invite was discarded, if applicable.

5. Commented Alternative Configuration

• # permit_params do ... end:
  The commented-out block provides an alternative way to define permitted parameters, similar to the previous examples. It allows for conditional parameter assignment based on the context, such as the action being performed or the role of the user.

Summary

This ActiveAdmin configuration for Invite records is designed to provide a streamlined and controlled way to manage user invitations within the admin interface. By excluding the new, edit, and destroy actions, it focuses on viewing and monitoring invites rather than creating or modifying them directly. The resource is organized under the "Users" menu, emphasizing its relevance to user management. The permitted parameters block is commented out, suggesting that if needed, administrators could enable and customize the parameters that can be modified.