Deleted resources can still be associated to other resources

[edwardmp]

I'm not sure whether this is actually expected to happen as this use case may not be within the intended scope of paranoia.

I have a model (let's call it Card) that acts as paranoid. I have another model (let's call it 'Event') that doesn't act as paranoid but belongs_to a Card. If I have an instance of a Card that was soft destroyed, I can still assign it to a new Event when I create it.

Is this expected behavior when using this gem? If so, does anyone have any suggestions as to how to prevent this (e.g. adding a custom validator checking that associations are not soft deleted before creating a resource)?

[BenMorganIO]

@edwardmp I would add a validation. I think this may be out of the scope of paranoia for creating new resources with the intention of using an object that has been marked as deleted. Some people use paranoia on products and change the deleted_at to unavailable_at, yet still want to perform operations on them.

Maybe:

class Event < ApplicationRecord
  belongs_to :card

  validate :card_is_alive

  private

  def card_is_alive
    return if card.deleted_at.nil?
    errors.add(:card, 'has been deleted')
  end
end

[edwardmp]

@BenMorganIO
Thanks. Seems we are on the same page as I opted for this in the meantime:

class AssociationNotSoftDestroyedValidator < ActiveModel::EachValidator
  def validate_each(record, attribute, value)
    # if association is soft destroyed, add an error
    if value.present? && value.deleted?
      record.errors[attribute] << 'has been soft-deleted'
    end
  end
end

This can then be used as:
validates :card, association_not_soft_destroyed: true

This might be of use to someone else. Although I agree that by default this would be out of paranoia's scope, might it be an idea to include this validator with paranoia for people to use?

[BenMorganIO]

@edwardmp if you'd like to make a PR to add this validation, I would love to get it merged in :)

[vraravam]

I have been thinking of the same issue - but from a different angle. In my case, I would still like the UI and the model-level validations to go through if I edit the Event (taking the same associations as above for illustrating my example scenario) - and as long as the associated Card was not changed, I don't want to raise a validation exception. But, if the card_id is changed, then it should point to a value that is not soft-deleted. Thus, depending on the action being performed, I would like the UI and the validations to work seamlessly for

1. a create action; vs
2. an update action that was not trying to point to a soft-deleted Card; vs
3. an update action that was trying to modify the related object to one that was soft-deleted.

Please see this gist. If this idea is good, I can make this into a gem and release it soon. (or), I could supply this as a PR for this codebase itself - wdyt?

[edwardmp]

Hey @BenMorganIO, I submitted a pull request that includes my validator, a test for it and an updated README. Please merge it in at your discretion.