Support ObservedBy on parent model classes

[adamthehutt]

When an Eloquent model extends another Eloquent model, the check for the ObservedBy attribute only considers the class itself. Any observers registered in the parent model are ignored.

This change adds support for the ObservedBy attribute in parent classes and traverses the hierarchy until the top Model class is reached.

[github-actions]

Thanks for submitting a PR!

Note that draft PR's are not reviewed. If you would like a review, please mark your pull request as ready for review in the GitHub user interface.

Pull requests that are abandoned in draft may be closed due to inactivity.

[taylorotwell]

Hey there! Could we get a test for this? Also should it keep going back up the tree in case there are multiple extensions?

[adamthehutt]

@taylorotwell You're too fast! :) I added another couple of commits after the initial draft pull request. These address the tree traversal issue you're asking about.

Will add a test ASAP.

[adamthehutt]

@taylorotwell Added a test. (Sorry about the sloppy commit history.)

[taylorotwell]

Thanks!

[patrickomeara]

This is a breaking change for me as I have a parent observer that creates polymorphic relationships, the grandchild model can't have these and doesn't have a morph map value.

Here is another example:

class MessageObserver
{
    public function created(Message $message) 
    {
        // send to all users
    }
}

#[ObservedBy(MessageObserver)]
class Message extends Model {}

class AdminMessage extends Message {}

Previously, creating an AdminMessage wouldn't send a notification to all users, now it is.

This PR takes away the granularity of adding the ObservedBy attribute where it's needed and assumes it can run for all child models.

Should we check for instanceOf in the observer methods?

[taylorotwell]

@patrickomeara hmm, tough call. I would say that the change we made is in line with the way other things work in the framework in general. For example, putting ShouldQueue on a parent class and dispatching the child class to the Bus will in fact queue it. Same with mail, notifications, etc. Or, registering a container callback to a parent type will get called for child types.

[patrickomeara]

@taylorotwell OK, that makes sense. Staying in line across the framework is the correct approach. In my case I will remove the inheritance and use the same table name. It's a hangover from a long time ago and feels like an anti-pattern now.