You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Adding a new option to available_dependent_notifications_options called nullify_notifiable.
Adding a new option to add_destroy_dependency for that key we defined before.
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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
(onacts_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 ofnullify_notifiable
comes to action.Expected solution
Steps to follow:
available_dependent_notifications_options
callednullify_notifiable
.add_destroy_dependency
for that key we defined before.Notifiable
module the new function which will update all thegenerated_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.
The text was updated successfully, but these errors were encountered: