: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.

[simukappu]

Thank you for this feature request! Before we proceed with the implementation, I'd like to understand your use case better:

1. Specific scenario: Could you describe a specific scenario where you need to keep notifications after the notifiable is destroyed? For example, is this for audit/compliance purposes, user experience, or analytics?

2. Display behavior: How do you expect to display these "orphaned" notifications to users? Would you show a message like "This content has been deleted"?

3. Current workaround: You mentioned using monkeypatching. Could you share how you're currently handling this? It would help us understand the exact behavior you need.

4. Soft delete consideration: Have you considered using soft delete gems (like paranoia or discard) for your notifiable models instead? This would keep the notifiable record and its notifications intact.

Understanding these details will help us design the best solution for this use case.

[simukappu]

Closing this due to inactivity. The design concern raised in 2020 (Notification validates presence of notifiable, so nullified records would be invalid) remains unresolved, and soft delete gems like paranoia or discard provide a cleaner alternative for this use case. If there's renewed interest, feel free to reopen with details on the specific scenario and how you'd expect invalid notification records to be handled.