"Repackaging" when upgrading or downgrading

[stuyam]

I like the pricing_plans methodology with how downgrades don't touch the product but allow you to show a feature is "out of compliance".

However I have a use case where I am packaging based on the number of projects in a users organization. Projects have the ability for the system to mark them as enabled or disabled because the system will keep monitoring and running stuff for those project unless disabled. The way the product currently works is I have a Package::Free package for example. Every package has a #repackage! method on it that is called when the package is set on that organization that allows us to do things like on the free account disable all but one project, or when upgrading, re-enable every project.

My question is, is there an existing way you think this could be accomplished today? Or do you think we could add some sort of hook to the pricing definitions that allows us to call a block of code or some service object to run these changes when a plan is assigned. Maybe like supporting an #after_assign hook?

One disadvantage to this approach is those hooks could change over time leaving some users in different states. But I think that is ok, that is more of a migration issue, and these hooks should be idempotent so they should be able to be called again.

Though I wonder if this creates any other issues with things like the default! plan? I can't tell if the default plan is saved or more of a fallback that is in memory and isn't actually being assigned? Just thinking through some ideas.

[stuyam]

I can see how this might be hard to include in this project since it seems like this project operates on a lazy loading of a plan meaning the plan is only picked up when you call it and not when the pay gem initiates any sort of change like a subscriptions has been created or not.

I was able to figure it out going more of the route of hooking into the pay gem. Here is what I ended up doing in case it is helpful to anyone in the future.

Create a PayExtension concern that will be added to Pay Subscriptions and is run on every create, update, or destroy of a subscription:

module PayExtension
  extend ActiveSupport::Concern

  included do
    after_commit :repackage_for_subscription, on: [ :create, :update, :destroy ]
  end

  def repackage_for_subscription
    organization = customer&.owner
    return unless organization.is_a?(Organization)

    RepackageService.new(organization).call
  end
end

The extension needs to be added to the correct Pay Subscription model on boot, this is added to config/initializers/pay.rb

Rails.application.config.to_prepare do
  # Ensure the concern is (re)loaded in development.
  require_dependency Rails.root.join("app/models/concerns/pay_extension.rb").to_s
end

# Hook into Pay's load hooks so we don't repeatedly include the concern on each reload.
ActiveSupport.on_load(:pay_subscription) do
  include PayExtension
end

Finally I just created a RepackageService class but this could live anywhere. I did it in it's own class rather than in the concern because I always wanted it callable for a Job for my use case.

@@ -0,0 +1,25 @@
class RepackageService
  def initialize(organization)
    @organization = organization
  end

  def call
    case @organization.current_pricing_plan.name
    when "free"
      repackage_free!
    when "pro"
      repackage_pro!
    end
  end

  def repackage_free!
    # disable all projects except the first one
    one_project = @organization.projects.first
    @organization.projects.where.not(id: one_project.id).update_all(enabled: false)
  end

  def repackage_pro!
    # re-enable all projects
    @organization.projects.update_all(enabled: true)
  end
end

[rameerez]

The pattern you worked out is now the blessed recipe in the docs, credited to this issue: docs/06-gem-compatibility.md, "Reacting to plan changes" (lands on main with the 0.6.0 release, PR #28). Two notes folded in from real-world use: keep the service idempotent so it doubles as a backfill job, and run it after manual override_pricing_plan! calls too, since those change plans without touching Pay.

A native plan-change callback in the gem itself stays open as a 0.7 candidate: the gem resolves plans lazily, so doing this first-class means wiring Pay's lifecycle hooks (plus Assignment writes) inside the engine. Leaving this issue open to track that.