Start with the Spec

Let's describe the desired behavior in RSpect and FactoryBot first for an imaginary Report object.

spec/models/report_spec.rb

RSpec.describe Report, type: :model do
  # I set up all FactoryBot factories to build with the 
  # required fields. In this case no fields are actually
  # required so I sub them in whenever they are under test.
  # In this case the absensce case is under test, so no attribute
  # is passed

  let(:report) { FactoryBot.build(:report) }

  describe 'validations' do
    it 'requires at least one field to exist' do
      report.valid?

      # important: make sure you are looking for the custom
      # key that you create, not a generic error
      expect(report.errors[:report]).not_to be_empty
    end
  end
end

Build the Custom Validator

Rails offers two kinds of custom validators: Validator and EachValidator. In this case, we want to pass in the entire record rather than a specific attribute, so we will go with Validator.

app/models/concerns/record_not_empty_validator.rb

class RecordNotEmptyValidator < ActiveModel::Validator
  def validate(record)
    unless non_id_attributes(record).any? { |attr| record.attribute_present?(attr) }
      record.errors.add(record.model_name.human.downcase!, 'must contain at least one attribute')
    end
  end
  
  private
  
  def non_id_attributes(record)
    record.attribute_names.reject!{ |attr| attr.include?('_id') }
  end
end

This code uses some Rails convenience methods to first remove any attribute names which contain the substring _id (which is useful for models with associations because depending on how you build the objects this field may not be nil) and then checks that at least one of the remaining attributes have a value. One thing to note is that if you examine the object ancestor chain you don't have a lot of ActiveSupport modules to work with so .human was the best method I could find to transform the model name. It's not strictly necessary to downcase the resulting key because it will be capitalized when shown in the view regardless, but my specs all assume that keys are lowercase so I include it.

Include it on the Model

Finally, you just need to call the validator on the model itself.

app/models/report.rb

class Report < ApplicationRecord
  validates_with RecordNotEmptyValidator
  ...
end

Handling Updates

The above code will work, but only for creating new objects. Let's say an object has been created and your user edits that object to remove all the fields. You would expect it to error, but it won't because there is now an id field that is not blank as well as created_at and updated_at fields (if you included timestamps in your migration).

To handle these we'll need to add some additional matchers:

app/models/concerns/record_not_empty_validator.rb

def non_id_attributes(record)
  record
    .attribute_names
    .reject!{ |attr| attr.include?('_id') }
    .reject!{ |attr| attr.include?('_at') }
    .reject!{ |attr| attr.match(/\bid\b/)
end

For the second reject statement, we'll assume that none of your real data fields include the _at suffix so we can match both created_at and updated_at fields. For the third, we will throw out any field that only contains id (which will only be the record primary key).

With those two additions you can now validate against updated records and all that's left to do is update the spec:

spec/models/report_spec.rb

RSpec.describe Report, type: :model do

  let(:report) { FactoryBot.build(:report) }
  # Assume report has a title field
  let(:saved_report) { FactoryBot.create(:report, title: 'title') }

  describe 'validations' do
  
    ...
  
    it 'precludes removing all fields' do
      saved_report.title = ''
      
      saved_report.valid?

      expect(saved_report.errors[:report]).not_to be_empty
    end
  end
end

If you are going to be doing this validation on a lot of models, you will probably want to pull this out into a shared example so it can included with one line.

As a final note: the docs indicate that you need include ActiveModel::Validations on the model, but I don't find that to be necessary.

Who Cares?

To hear Vim users, and yes emacs users too, talk about how much they love their editors can really make you feel like you are missing out on something cosmically amazing. Personally, I thought it was 50/50 on whether they had actually unlocked something valuable or had Stockholm Syndrome after such a long period of suffering. But still, once you have watched someone who is amazingly productive in Vim, it's hard to get the thought out of your head that you could be (a lot) more productive. To watch someone accomplish in a few fluid keystrokes everything that they need before your hand can finish reaching for the mouse is awe inspiring in the singularly nerdy way that only those who write code into a terminal for a living (or fun) can be inspired.

But, you know why you're here. You want enlightenment. You want to hear it's worth it. All the time and the struggle and brain hurt of trying to remember what motion gets you where. You want to be done already. And you can be, but I would suggest that you take the long way to get there.

(don't) Delete the Editors!

I'm sure you've heard deprivation stories before. What's a deprivation story? It's when a new analyst starts at a bank and to force them to learn Excel keyboard shortcuts their mice are taken away. For programmers it's uninstalling all other editors and forcing yourself to use Vim until you get good at it. If you go really deep it doesn't stop there either, I heard Ben Orenstein recommend once that you should lower your key repeat rate to force yourself to learn better navigation instead of using hjkl as a crutch. The path to enlightenment is never done.

For me, and I imagine if you're reading this, for you also, the deprivation angle didn't work. My theory on why it doesn't work is because if you are interested in using Vim you are probably interested in being more productive and a program that causes you to regress to what feels like your first touch typing lesson is frustrating. In the short term it's definitely counter productive.

But, I hear you say, I learned touch typing by just gutting it out and you can learn Vim this way to! This is, of course, technically true. I doubt you would quit your job if you could only use Vim and after a period of time you would become proficient with it. That period to proficiency would also probably be shorter, if more painful.

Why doesn't everyone do this?

One, we aren't starting from 0. When you first learned to touch type you had no other option to than to get through it (or live with your hunt and peck shame forever). This is the nature of beginning something wholly new. If you are already writing code though, typing isn't wholly new and Vim can represent a step backwards.

Second, for most of us this isn't a theoretical exercise (unless you are in college or otherwise have extra time on your hands, then I encourage you to try whatever drastic approaches you want), most of us have to produce things and if you're reading this blog, you probably have to produce characters, lots of them, in not enough time.

What Worked for Me

Here are the steps I took over the course of about a year that finally got me switch over to Vim full time:

• vimtutor, got the basics, finally understand what this actually is
• Try to use some Vim and a lot of Googling to write real files, give up when frustration reaches crtical mass, repeat for months
• Try VimGolf, get more frustrated, decide Vim was a stupid idea anyway
• Start popping open Vim for specific edits based on known skills, it's becoming a part of the toolset
• Actually invest the time to manage ~/.vimrc; amazement returns, but still far faster in old editor
• Find a few plugins that handle specific annoyances, opening up Vim more and more
• Discover something amazing (was ctrlp for file navigation for me); begin guessing at commands that "should" work and they do
• Experience the tipping point: realize it would be faster to do something in vim, close other editor, vow to never come back
• Realize that other editors are often still good for creating files, so, in the end, it's not all or nothing

The Secret: Deliberate Customization

As I look back over that list I see someone grappling with the basics, gaining proficiency then finally mastery (then the final final step of realizing it's not some panacea that solves everything). What really made Vim worthwhile though was customization and plugins.

Start Out With Something (but not too much)

Customization will make any editor more comfortable. With Vim, however, I would argue you must customize to be productive. This isn't a new thought, there are a lot of bundles that dump in a bunch of config and customization into Vim all at once. The downside is that these bundles separate you from customizing Vim yourself. It becomes like just another editor with behavior you may not like, but limited ability to change (is that a Vim behavior or did it come from the bundle?). In the end you want your Vim config to be a special snowflake, your special snowflake.

After trying out some of the bigger config dumps, this was the one that worked for me. It's not too big and the changes are nice QoL increases. One note, I would remove the Vundle loader. Vim packages makes this unnecessary and if you are just starting out, I'd suggesting going this way as it seems like the future and is built in. Here you can read a longer discussion about packages.

A (very) short list of things to change now

Here is a deliberately small number of things that I would change right now as you are experimenting with Vim:

• Remap capslock to escape. Esc just too far away and too small and you're going to be hitting it all the time (and you're out of luck if you have a Mac without one).
• Remap your leader key. Mine is ',' but it doesn't matter what it is only that it's comfortable for you and your workflow.
• Get a file navigation plugin (I use ctrlp, but find one you like). This alone will make you faster in Vim.
• Take the time to groom your wildignore list. Don't waste time returning files you aren't going to open anyway.
• Set a small number of leader commands that you will use right now. Work in Rails and always checking the schema? Try map <Leader>db :sp db/schema.rb<cr>. Work on files where spelling is important? map <Leader>sp :setlocal spell spelllang=en_us. Whatever you pick make sure you use them often so they stick. This will grow just like your alias list in bash.

So take heart. You can learn vim. Just take a break when you need to. It will still be there when you come back.

Relationships are referenced by attachments with the record_type attribute where record_type is the name of the model. Here is an example attachment where the model name is Training::Hike:

#<ActiveStorage::Attachment id: 8, name: "files", record_type: "Training::Hike", record_id: 1, blob_id: 9, created_at: "2018-04-23 13:54:27">

Once you update the table name (and the models and controllers and the file names etc etc) update the record_type with a simple query:

ActiveStorage::Attachment
  .where(record_type: 'Training::Hike')
  .update(record_type: 'Training::NewModelName')

Now you just have to update all those tests ;)

How to delete attachments

At the time of this writing, the Rails Edge Guide detailing removing attachments is all of two sentences and two methods long. You can purge them now or you can purge them later. Note, for this post we will only talk about purge rather than detatch which calls destroy_all the attachments, but leaves the blob(s) intact.

For has_many_attached the default behavior of purge is to delete all the records (obviously the same is true of has_one_attached), however, you can target them for specific removal with any query. To get a better idea of how the objects are shaped, here is a Resource object which has two :files attached

Resource.last.files
#<ActiveStorage::Attached::Many:0x00007f8ff866e470 @name="files", @record=#<Resource id: 1, title: "Testing", created_at: "2018-04-17 16:30:29", updated_at: "2018-04-17 16:30:29">, @dependent=:purge_later>

Resource.last.files.first
#<ActiveStorage::Attachment id: 1, name: "files", record_type: "Resource", record_id: 1, blob_id: 1, created_at: "2018-04-17 16:30:29"> 

Resource.last.files.last
#<ActiveStorage::Attachment id: 2, name: "files", record_type: "Resource", record_id: 1, blob_id: 2, created_at: "2018-04-17 16:30:29">

The name assigned to each record is the one that you set in the model and will be the same for all attachments on that model. The specifics about the file itself are in the blob

Resource.last.files.first.blob
#<ActiveStorage::Blob id: 2, key: "9BG2pTG3S7Ms4jfVa9ysj33F", filename: "Test_file.PDF", content_type: "application/pdf", metadata: {"identified"=>true, "analyzed"=>true}, byte_size: 78618, checksum: "kG/rsqFbw/BkHSSPYItqAg==", created_at: "2018-04-19 19:17:27"> 

To remove all the attachments from either a has_one or has_many model, just target the attachment and call .purge on it. To get rid of a single attachment from a has_many_attached record, you can use a query:

# Directly
ActiveStorage::Attachment.find(1).purge

# Through a resource
@resource.files.find(params[:attachment_id]).purge

What to do about controllers

For me, the above discussion is interesting, but only the start. Yes, you know can target attachments and purge them, but as soon as you sit down to wire this up to a user action you will be confronted with where exactly to put it.

Interestingly, this is not an issue that the other actions have. Creating attachments doesn't require anything extra on the create action. Updating attachments will work great on the update action as long as you remember that updating a has_one_attached relationship will destroy and replace the old file and updating on a has_many_attached will create a new attachment. Neither of those requires anything explicit to work for ActiveStorage other than whitelisting your attachment name.

Here are three options I see on where you can locate your attachment deletion responsibilities:

• a global attachments controller that handles all delete requests
• a non-restful endpoint and method on the resource controller
• a switch on the resources destroy action

I think each has their pluses and minuses depending on your application and how closely you want to hew to REST.

A global attachments controller

A global attachments controller keeps things nice and clean. For example, you send your deletes to /attachments/:id, dust off your hands and call it day. For many apps I can see this working. In some ways it kind of feels like this is a missing controller for ActiveStorage.

One disadvantage that comes to mind, however is that now the destroy method is separated from any before filters, authorizations or controller logic specific to the resource controller. This may or may not matter to you, depending on your use of callbacks.

A second disadvantage is that it's not quite as simple as just passing in the ID in the case where you want to purge only one record from as has_many_attached model. You could handle this in a number of ways, but it seems certain to involve some conditional logic.

A non-RESTful endpoint

This was the first tool I pulled for when thinking about this issue. It makes your routes a little messier and there's another method in the controller, but all-in-all, it's not so bad. And, if you're making one endpoint, you might as well make 2 and then you can handle purging all attachments and selectively purging attachments without conditionals. This way you also get any controller specific callbacks and methods.

The reason I moved away from this, and I think it's primary disadvantage if you aren't worried about being completely RESTful, is that I had a lot or models that were handling files and building in this endpoint to each one was feeling like a lot of repeated work. I could still see it being worth it if you are doing a lot of controller specific work depending on where the delete was coming from, but in my case, all the destroy actions were the same.

Switch on the resource's destroy method

For this approach, you don't have to mess with your routes or manage additional methods. I built mine to pick up on an [:attachment_id] param or a [:purge] param. If it's present, it handles the attachment(s), if not, it destroys the resource just like always.

Here is an example of a has_many_attached model:

# handle selective purge
if params[:attachment_id]
  @resource.files.find_by_id(params[:attachment_id]).purge
  ...
# handle purge all
elsif params[:purge]
  @resource.files.purge
  ...
# handle destroy resource
else
  @resource.destroy
  ...
end

The disadvantage is you need to deal with a conditional and it feels a bit like hijacking the destroy method, but for my current use case it's been pretty manageable.

child.parent.parent_attribute

Meta-note: parent/child metaphors are not 100% apt for SQL and break down in a lot of examples. Below are "children" that all have a foreign key referencing their "parent".

A Example

You are creating two records: Meeting, which only has a date and MeetingPresentation, which will carry some other information, but isn't important for this example.

class Meeting < ApplicationRecord
  has_many :presentations, dependent: :destroy
end

class MeetingPresentation < ApplicationRecord
  belongs_to :meeting
end

Now, let's say you want to loop over all the presentations in an index view, but you also want to display the meeting date attached to them. Getting the date is super simple:

< @presentations.each do |presentation| %>
    <%= presentation.meeting.date %>
<% end %>

A more complex example might be if you want to perform some kind of validation on the parent attribute before displaying. For example, assume that users are not allowed to edit a presentation on the meeting date or after. Using the validation module discussed here, you can selectively not show them the edit button like so*:

< @presentations.each do |presentation| %>
    <%= presentation.title %>
    
    <% if authorized?(:edit) && presentation.meeting.date.future? %>
      <%= link_to edit_presentation_path(presentation) %>
    <% end %>
<% end %>

*obviously you want to lock this down in the model too with a validation, not showing the button is just a convenience

Why Was This Confusing

If you already knew this, I imagined you stopped reading by now, but if you're still here, I think it's worth asking, why wasn't this obvious to me (and maybe you). For me, I had viewed ActiveRecord one-to-many objects as linear associations which only flowed downward because all the manipulation that I was doing to them involved linear parent -> child modifications.

If you have two objects set up like the example above and you try to save MeetingPresentation.new(title: 'title') it will error because you haven't told it what meeting it's attached to. You can manually pass in the meeting_id as part of the hash, but more realistically, you will define a meeting and then build the relationship so that you don't need to know what that meeting_id is:

@meeting = Meeting.find(params[:id])
@meeting.meeting_presentations.create(title: 'a title')

Additionally, when you want to manipulate an already created record, you most often call either the record itself or, if it's a collection of records, that collection from the parent. Though it's possible to edit a parent relationship from the child, it's probably not advisable to do so unless you have thought out your specific use case. For example, the following will work:

presentation = MeetingPresentation.last
presentation.meeting.update(date: 5.days.from_now)

If there were 3 other presentations associated with that meeting, "their" dates (through the parent) have also been changed. Again, there may be a specific reason do make this change like this, but I think it should be carefully considered.

This was my mental model before. After closer examination though, this should make sense. Whether you are calling the parent or child, you are really just calling an _id. In this frame of mind, it doesn't matter which "direction" things are going. In fact, the idea of directionality doesn't make sense (and neither does the parent child analogy, really).

How to make use of this behavior

Displaying information in the view

Displaying parent info, as in the above example, is useful if you have normalized your DB so that there is little duplicated information and a lot of ID references. Instead of doing a DB lookup in the view or declaring additional variables in the controller, you can just simply call and display the parent attribute from the child.

Links

If you have nested resources you will need to pass in both the parent and child IDs when targeting a child record. Collections (like an index of child records), may or may not need to display parent records. Extending the example above, imagine we want to show all the presentations organized alphabetically regardless of meeting date and give users buttons to edit and delete them. Assume that the loop variable is |presentation| and that presentations are the lower nested resource, you can call links as:

<%= link_to edit_meeting_presentation_path(presentation.meeting, presentation) %>

Validations

In the validation example I said you should lock down the model as well as not show the link. One way you can do that would be an ActiveRecord hook that makes use of the parent attribute:

class MeetingPresentation < ApplicationRecord
  validate :verify_valid_meeting_date, on: [:create, :update]
  
  private
  
  def verify_valid_meeting_date
    unless self.meeting.date.future?
      errors.add(
        :meeting_presentation, 
        'cannot be created on or after a meeting has taken place')
    end
  end
end

Parent update

Okay, yes I said this wasn't a good idea, but I thought I would lay out a hypothetical in which this might be what you want to do (it's admittedly a bit contrived). Let's keep with the meetings and presentations example. Users give many presentations and some of those presentations may be classified. They are also the only ones who are allowed to modify the presentations which they own (but not the meeting directly). For some record keeping authority, you need to classify any meeting which contains classified presentations as such.

At this point you can just loop through all the children to see if any presentations are classified and return a true/false on whether the meeting is classified, however users may mark their presentations declassified at a later date and the record keeping authority requires that any meeting which ever contained any classified presentations remain categorized as such (I told you it was a bit contrived, though I have seen some business requirements that are worse).

Now we set Meeting to have a has_classified boolean that defaults to false and update that any time a user submits a presentation with a boolean of is_classified equal to true.

class MeetingPresentation < ApplicationRecord
  after_commit :mark_meeting_classified
  
  private
  
  def mark_meeting_classified
    if self.is_classified
      self.meeting.update(has_classified: true) unless self.meeting.has_classified
    end
  end
end

It happens to all of us sometimes. We find a really useful tool and, once found, we keep reaching for it over and over again even when it might not be the best fit for the problem we want to solve. Sometimes it's worth going back to the docs to see if there is a better solution when your environment changes.

My most recent experience with this was Rails full_messages method. Since I started learning Rails using Michael Hartl's book, I have been building controllers with branching logic to handle validation errors and wondering at the magic of it all. When you combine full_messages with the traditionally rendered pages and flash it makes displaying an unknown number of errors to the user really convenient.

The difficulty came when I started stripping out ERB in favor of Vue and running Rails in API mode. Now, delivering a bunch of strings in an array that gets dumped into a div seems like a gross underutilization of what's possible. Even something as simple as placing the error under the field that has failed validation requires a bunch of extra work (e.g. RegEx), but why work harder than you have to.

Here is how to leverage Active Model errors to deliver usefully formatted JSON objects to your front-end framework.

Active Model Errors

First let's take a look at what error methods are available. The Active Model Errors pages is a great resource for seeing all the things you can do with error messages, but let's focus on the subset of error messages that return messages as key/value pairs and how they are formatted.

What are ActiveModel Errors anyway?

If an ActiveModel validation fails, it delivers an ActiveModel::Errors object, the most relevant portion being the @messages variable. Here is a simple example for a made up model called Item:

#<ActiveModel::Errors:0x00007fe63fcff710 
  @base=#<Item id: nil, name: nil, user_id: 15, created_at: nil, updated_at: nil>, 
  @messages={:name=>["can't be blank"]},  
  @details={:name=>[{:error=>:blank}]}>

You will also notice that there is an @details hash that will also give the type of error. This could be useful if you don't like the ActiveModel errors text and want to display your own text on the front end after matching on the error type (which is way more convenient than writing your own error messages in the controller).

Sending errors

To send the errors as key/value pairs, you can call .to_hash or .as_json which are defined in ActiveModel::Errors. Though it's not documented, you can also use to_json which will result in the same output, but doesn't allow you to use full_messages as shown below.

Note: You might be tempted to call the ruby method to_h on item like @item.errors.messages.to_h which will return the key/value pairs with a string as the value, but doing this will ignore any validation messages after the first one which is fine if you only have one validation, but makes your controller brittle to changes in the future.

Adding detail

The nice thing about both the to_hash and as_json methods is that they will take an optional argument to set the value of full_messages. Like the full_messages method mentioned at the top, this will include both the name of the object as well as the validation failure in human readable format. The useful thing here is that it is still tied to the object name as the key so your front-end doesn't need to do anything other than display the message(s) after matching on the key.

To include full_messages call errors like this:

@item.errors.to_hash(true)
  or
@item.errors.as_json(full_messages: true)

which will deliver a hash shaped like this:

{
  "name": [
      "Name is too long (maximum is 2 characters)",
      "Name has already been taken"
  ]
}

A little bit of cleanup

Personally, I like to wrap my error messages in an error key this way the front end gets not only an HTTP error code, but also an explicit error hash.

if @item.save
  ... do stuff ...
  }
else
  render status: 422, json: {
    errors: @dealsheet_view.errors.to_hash
  }
end

This is one way to return formatted errors as JSON, but of course, that's not the end of things. Once you see that ActiveModel::Errors is returning two hashes with differing levels of detail, there is really no limit to how you can manipulate this output to get exactly what you want for your use case.

If you have been following Font Awesome's development, you have probably seen the shiny new version 5 which changes the recommended way to include the icons. The How to Use section provides some great documentation, but sadly a Rails walkthrough is not to be found.

So, here's what we're going to set up:

• Download and serve only the light theme to save on file size
• Fix a gotcha when using Turbolinks that keeps icons from displaying on every page

Download and save files

When you download Font Awesome and unzip the files, you will see quite a few folders in the tree. The two you need are:

• fontawesome-pro-#{version}/svg-with-js/js/fontawesome.js
• fontawesome-pro-#{version}/svg-with-js/js/fa-light.js (or whatever specific style you want to include)

Copy these two files into your app/assets/javascripts/ folder. I'm, assuming that you are going to run these through Uglifier so there's no reason to opt for the minified versions.

To test that this is working, throw an <i class="fal fa-user"></i> onto a page and see it display.

Make Font Awesome play nice with Turbolinks

First and foremost, credit to Michael Minton for posting a coffee-script example of how to do this (he also has a solution for layout shifting you should check out).

It won't be too long before you realize that you sweet Font Awesome icons are not displaying on every page, but only the first time the page is loaded (or refreshed). The problem (or complication if you prefer less accusatorial language) is Turbolinks. To fix this, you want Font Awesome to re-render the icon whenever the turbolinks:load event is triggered.

Add a new file with the following (note: I added jQuery back into my project to use with Bootstrap):

(function() {
  $(document).on("turbolinks:load", function() {
    return FontAwesome.dom.i2svg();
  });

}).call(this);

Alternatively, if you are using CoffeeScript, you can use Michael's example linked above.

So, there you go, Font Awesome Pro in the Rails asset pipeline using just the files you need. You could get the file size even smaller if you go through and delete the SVGs of the icons you aren't using, but I'll leave that up to you.

Update 17 April 2018: At the bottom of this post, you will find modifications that will let you use this with namespaced classes.

I was recently working on a project that needed user authorization. I knew people who had used cancan before with some success so I started by looking through the repo and trying a small scale test. There were a few problems that made the gem not a perfect fit which I'll run through below as well as the solution I came up with.

Situation:

• Every resource behind the login page has a differing level of authorization
• There are at least 5 groups who have different permissions for different resources
• Users can belong to more than one group
• I only want to maintain one user model that can easily move members from one group to another

Options with cancan

It is possible to do one user model with multiple roles in cancan. The wiki lists a walk through on how to set this up, but this seemed a little involved and not exactly in keeping with the main use case from the Readme. Someone has extracted this model into a gem but it hasn't been updated in a few years and using a gem on top of a gem seemed to validate my gut feeling that this was more complicated than it needed to be.

Implementing it myself

Goals

1. One user model, multiple roles
2. A permissions hash that is easy to scan and modify
3. A simple before_action on the controllers to check authorization
4. A view helper that can conditionally display items based on the current users level of permission

Goal 1: Assigning roles

I was already using Devise for user authentication so I added a user role column to the model for roles.

db/migrations/...

class AddRoleToUsers < ActiveRecord::Migration[5.2]
  def change
    add_column :users, :role, :string, array: true, default: []
  end
end

In the future I thought we might want to have the option to initialize users with a different class so I set up a before_save hook on the User model instead of defaulting the role in the migration.

app/models/user.rb

class User < ApplicationRecord
  before_save :assign_user_role
  
  private
  
  def assign_user_role
    self.role.push('user') unless self.role.include?('user')
  end

Now we can create users with roles and know that they will always be at least assigned the role of 'user' and we don't duplicate that role if it's passed in create.

Goal 2: Permissions hash

I wanted the permissions hash to be easy to scan at a glance and see what groups were authorized to do what. Moreover, I wanted it to be easy to call using the current_user helper that comes built in with Devise.

To do this, I created a module that can be mixed in to User.

lib/modules/policy.rb

module Policy
  # All members are users therefore any action for which a user is authorized
  # can be performed by all members

  def authorize(role, controller, action)
    policies = {
      wiki: {
        show: %w[user],
        index: %w[user],
        edit: %w[admin moderator],
        update: %w[admin moderator],
        new: %w[admin moderator],
        create: %w[admin moderator],
        destroy: %w[admin moderator],
        dynamic: %w[user]
      }
  if !((policies[controller.to_sym][action.to_sym] & role).empty?)
      return true
    else
      return false
    end
  end
end      

The hash is pretty easy to scan. You can see at a glance what the controller is and what the actions are. In this case, we have 7 RESTful actions as well as one custom action that gathers up wiki topics dynamically.

To authorize the user, it looks up the controller and action in policies, then uses & to check for set intersection, call .empty and negate the result using !. If the set intersection finds any roles in common, .empty will return false which means the user is authorized in our case, so we use the bang to negate and it reads a bit more naturally since authorize should return true if the user role is contained in the authorized roles.

Then, include the module on User

app/models/user.rb

class User < ApplicationRecord
  include Policy
  before_save :assign_user_role
  ...

If you like to save your modules under /lib remember to include it in the auto-load path

config/application.rb

...
config.autoload_paths += %W(#{config.root}/lib/modules)
...

Goal 3: A simple before_action

Before the before_action can be called it first needs to be defined. In this case, every action in the site requires authorization so I defined the action on ApplicationController

app/controllers/application_controller.rb

def authorized?(action="#{action_name}", controller="#{controller_name.singularize}")
    current_user.authorize(current_user.role, controller, action)
end

def authorize
  redirect_to unauthorized_path unless authorized?
end

This takes advantage of string interpolation to take the values being passed around from the controller name and controller action.

Jumping ahead just a bit, you can see that I set a default value for action and controller so it can be called on the controller without any arguments, but still have the option to pass a specific action and controller in the view. redirect_to could have been called directly on the authorized? method if you don't need this, but by separating them out you will be able to use authorized? :edit as a view helper later or authorized? :edit, :controller_name if you want to check against another controller.

Now on the controller a simple before_action is needed:

app/controllers/your_controller.rb

class WikisController < ApplicationController
  before_action :authorize
  ...

Goal 4: A view helper

All the above works great to lock down your controller actions, but you don't want users to constantly be being sent to an unauthorized page every time they click on a link they don't have the permissions to do anything with. To clean this up using the authorized? method, it is first necessary add authorized? as a helper method:

app/controllers/application_controller.rb

...
helper_method :authorized?
...

Now, let's say in the view you have some users who are allowed to edit entries, some that are allowed to delete them and some that can do neither, this has you covered.

app/views/controller_name/show.html.erb

<%= @item.title %>

<% if authorized? :edit %>
  <%= link_to edit_item_path(@item) %>
<% end %>

<% if authorized? :delete %>
  <%= button_to "Delete", { action: "destroy", id: @item.id }, method: :delete %>
<% end %>

As written, this will default to the controller that is behind that view, but I find it useful on pages that are collecting different links to be able to authorize against a different controller. For example, if your show or index page is pulling in any associated data, you can drop an edit or delete button for that association and save the user a page load.

<% if authorized? :edit, :controller_name %>
  <%= link_to edit_item_path(@item) %>
<% end %>

Update: One things that I ran into while using this is is does not work with namespaced classes. The reason it doesn't work with namespaced classes is that the method controller_name that is used on the original example actually strips outs modulization. PS: learning that Rails has a demodulize method was a surprise for me; it seems like there are many weird and wonderful things in ActiveSupport.

Not the most elegant way, but this will make namespaced classes work:

def authorized?(action="#{action_name}", controller="#{self.class.to_s.gsub('::', '_').gsub('Controller', '').underscore.singularize.downcase}")
    current_user.authorize(current_user.role, controller, action)
  end