:nullify_notifiable option on :dependent_notifications

[christopher-avila]

Problem or use case

The use case that explains this feature is for those applications which want to keep the track of notifications even if a notifiable has been destroyed. With the current implementation, we can skip deletion of dependent notifications by not passing any parameter to dependent_notifications (on acts_as_notifiable), which is the default behavior but in this case this results in having the notifiable_type and notifiable_id pointing to an unexisting record. Even if this is a correct approach, some cases needs to clean this kind of information. That's where the option of nullify_notifiable comes to action.

Expected solution

Steps to follow:

1. Adding a new option to available_dependent_notifications_options called nullify_notifiable.
2. Adding a new option to add_destroy_dependency for that key we defined before.
3. Defining into the Notifiable module the new function which will update all the generated_notifications_as_notifiable_for(target_type) to notifiable_type and id to nil.

Alternatives

For this approach I did not find any easy way to do this without monkeypatching, which has been the solution I've took.

[simukappu]

I think this requested feature is clear, but just wonder what its use cases are. Are there any use cases you would like to nullify notifiable, not deleting notifications? Notifications without notifiable record do not work in your application.

Thank you for your pull request. I would appreciate it if you could write RSpec tests of this new :nullify_notifiable option.

[simukappu]

In addition, Notification model has a validation for presence of notifiable.
https://github.com/simukappu/activity_notification/blob/master/lib/activity_notification/orm/active_record/notification.rb#L51

If we add this nullify_notifiable dependent option, updated notification records will be invalid. We have to consider and design more details about this enhancement request.