CODEWITHSUNDEEP
ruby-on-railsversioningpaper-trail-gem
dennismonsewicz
dennismonsewicz

Reputation: 25542

Rails/PaperTrail: approving edits

In the app I am working on we are using PaperTrail to not only keep up with changes made by the original user but also by changes that have been made to a User with a role of "Contributor" who has access to make changes to authorized profiles.

The one piece I can't put together is not allowing unapproved paper_trail versions to not show up as "live". We will be building in a dashboard area where the Profile Owner will approve edits. Just needing some guidance. Thanks!

Upvotes: 4

Views: 554

Answers (1)

lipanski
lipanski

Reputation: 1763

I would use two different classes: one to hold the live, approved User, the other one to hold the contributed, unapproved User. Let's call them User and PendingUser.

You can have PendingUser inherit everything from User and just overwrite the table_name. Or, event better, both can have a common class they inherit from - e.g. BaseUser (or a common concern). You'll also need a reference to the original User (PendingUser#user_id), in order to know, who the changes belong to. So you'll need to write migrations for the pending_users table and something like this:

class BaseUser
  # Everything that used to be within your User class
end

class User < BaseUser
  self.table_name = 'users'
  has_one :pending_user # Or has_many, see the last paragraph
end

class PendingUser <  BaseUser
  self.table_name = 'pending_users'
  belongs_to :user
end

Now there are two ways of setting up PaperTrail, which will lead to two different approaches:

  1. The default way - PaperTrail stores everything by using the Version model. This means both User and PendingUser will be serialized in here, so no need to change anything

  2. Specialized classes & tables: PaperTrail versions Users as UserVersion, which means you'll need to provide a PendingUserVersion class & table (pretty simple, just inherit everything from UserVersion, appart from the table_name).

So far so good. If your contributors are allowed to see pending users created by other contributors, then you're pretty much done - you'll just want to write the logic for the approving mechanism: basically you copy the attributes of the live version of a PendingUser to the live version of a User (except for PendingUser#user_id of course). After approving changes, you might want to remove the PendingUser and the PendingUser versions, or pick up all these versions and change their class to User (merging unapproved versions with the approved ones).

If your contributors are not allowed to see each others pending contributions, then you'll be having a User has-many PendingUsers relationship. It might get a bit more complicated, because you'll need to think about how, after approving a User, all other PendingUsers made by other contributors will referr to an outdated User version.

Good luck!

EDIT: Added the User reference to PendingUser.

Upvotes: 3

Related Questions