Robert Ault

Wow, my apologies to everyone for the formatting. The carriage returns were ignored here and I don't know why. Look for "Papertrail: " concatenated after "Audited: " in the first 3 sections for its specifics.

I'm literally just looking at this myself and this thread is all I can find on the topic of audit logging on gorails. This is my first draft, meaning I could've missed or misunderstood something when looking over these gems.

Audited: simple and easy to implement

• 20M downloads on rubygems
• source has fewer forks, might indicate fewer changes needed
• tested with latest-ish major versions of rails and ruby, still trailing behind, possibly for backward compatibility Papertrail: simple and easy to implement with a well defined pathway towards more complex scenarios
• 800k downloads on rubygems
• source has more forks, might indicate more changes are needed
• increase in logical and code complexity when deviating from the default
• up to date with major versions of ruby and rails
• readme tells of a breaking change in its history, you may run across older apps pinning an older version of the gem

Audited: one table for all audit records

• easier for full app audit reporting, can still easily extract per model audits using the type column
• could be a large table over time Papertrail: one table per model suffixed with "#{Model.table_name}_versions"
• easier for per model reporting/display
• isolates table growth to know high use models
• more cumbersome to combine audit logging across multiple tables

Audited: stores attribute changes

• smaller disk footprint
• inherently limits historical view of an object
• requires walking/merging changes to show full history
• model changes are easier to traverse history over time
• current version is in the model's table and must be looked up there Papertrail: (now) stores full changed version of object
• can delete any timeframe and recreate the original version of the object
• easily shows full history
• model changes will require more complex code to traverse history over time
• can't find where a current version is stored but you can call a method and get it from the gem regardless

Audited: can implement undo feature

• requires (MORE) code to walk back through history merging changes Papertrail: versions allow easy implementation of an undo feature
• requires (LESS) code to walk back through history merging changes

Audited: reasonably documented considering its simplicity, missing examples for common modifications
Papertrail: extremely well documented, almost suspiciously so

Both can be turned off or on at will.
Both can specify which attributes to log.
Both can specify which actions to log.
Both automatically log the user responsible using current_user, probably because of the popularity of Devise.
Both offer configuration locally per model and globally through initializers, Papertrail offering more options.

Summary:

If your app needs simple audit logging where deviations from the default of the gem should be done simply, you're probably better off with the audited gem with a known cost of needing to engineer different behavior. If your app needs a robust undo feature or you have models you know are modified frequently that requires faster access to a previous version, you're probably better off with Papertrail with a known higher cost of dealing with alterations of the gems behavior and possible breaking changes to the model's structure as the audit history grows (you can optionally migrate a data change with the model change). One option might be to start an app's lifecycle with audited and switch to papertrail at the point it outgrows a single table audit log or needs a robust undo feature, making the added costs of multiple database tables marginal/acceptable.

Caveat: Neither inherently supports I18n. If that's necessary in the audit log context, you may want to try something like public_activity as I18n is built in and the gem has about 9M downloads on rubygems. However, that gem's intent is a bit different than specifically audit logging. (see it's readme)

Simply:

For a simple audit log: Audited
For reification(undo) and diffing: Papertrail
For (simple) audits with internationalization built in: PublicActivity

Given Chris's experience, I'd defer to his opinion over mine. Maybe he'll do a video on comparing these and have a different perspective than I have? I hope my review helps others chose the right option for heir application. There are of course other gems for audit logging too.

SPAM comment reply, do not click the link

SPAM

When you see an error like this, you need to try installing the gem that won't install and check its specific error message for the next step. Try this, then troubleshoot that error:

gem install bcrypt -v 3.1.18

Your problem might already have a discovered solution. Always check the gem's Issues page in it's GitHub repo:

https://github.com/bcrypt-ruby/bcrypt-ruby/issues

The error says it can't find a C compiler so you need to install one. CMAKE is probably what you want. https://cmake.org/install/

From a senior dev...

1. Have a tenant table that stores the domain
2. Add tenant_id to devise users table for lookup
3. In the application controller, match up devise's current_user object with the request.domain: https://github.com/ErwinM/acts_as_tenant#manually-using-before_action.

Allowing tenants to point to their own domains with subsequent SSL certificates is not Rails related. You probably already know there's no such thing as internet based wildcard root domain certs, and to be honest, I can't think of an intranet problem that solves either. So, you'll need to setup API access for domain registration (you choose) and automate cert generation to go with it, unless the domain registrar has that service (most do). Then call that code through normal view/controller actions.

There's not much to configure in Rails for SSL, https://guides.rubyonrails.org/configuring.html#config-ssl-options.

The domains will need set in Rails 7 config as explained here: https://guides.rubyonrails.org/configuring.html#configuring-middleware.

You'll have to restart your own Rails app for it to pick up the config changes because you can't really turn a rails app into a web host. 👀

This isn't going to work, but thanks for the chuckle. Hope you figure it out though!

This is great, thank you.

I'm wondering, just to round out the initial Wordpress example, can you briefly describe what is needed to be done to land on lvl.me (like Wordpress.com), login, then get redirected to your subdomain's personal landing page?

Maybe a "Handling Subdomains and Multitenancy From Scratch" part 2? It's kind of a fun topic. :)

Here's my code from this video in Rails 7: https://github.com/robault/CustomSubdomains

This is not a solution and the code is bad, but since the NPM package is outdated as well as the ruby gem, it at least "works" in Rails 7: https://github.com/robault/event_scheduling

Uses an updated version of the Ruby gem to Rails 7.0.4 and Ruby 3.2.2: https://github.com/robault/recurring_select

This is not a solution and the code is bad, but since the NPM package is outdated as well as the ruby gem, it at least "works" in Rails 7: https://github.com/robault/event_scheduling

Uses an updated version of the Ruby gem to Rails 7.0.4 and Ruby 3.2.2: https://github.com/robault/recurring_select

We just built an IOS app using turbo native in Rails 7.
https://turbo.hotwired.dev/handbook/native

You may be able to upgrade rails and take advantage of the new turbo framework. Here's the GitHu repo for IOS:
https://github.com/hotwired/turbo-ios

And here's android:
https://github.com/hotwired/turbo-android

This allows you to create a native app (in our case Xcode) from web views in rails without heavy lifting in Swift. The turbo native lib wraps the remote views in native layouts and interaction/behavior. Not only that you have some control over your app from the rails side after it's deployed. After people pick up Hotwire a bit more I wouldn't be surprised if this becomes the standard for Rails -> mobile. It's surprisingly easy and powerful. Most of your work (like ours) will be on the rails side, not Swift/IOS.