-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Model Observer to tenant belonging models #50
Comments
So to reproduce: Add Landlord Trait to a model (e.g. User), add Observer to the model User::observe(UserObserver::class); and try search on it. It will ignore the tenant assignment. |
This works fine for me, if I understand correctly. What exactly are you trying to do that isn't getting scoped? |
Maybe related to #45, have you tried with other models than |
Just come across this issue myself. Adding an observer to a model stops Landlord from working(!) |
It seems that the order is of essence. If you run Landlord::addTenant() first everything works fine (the tenant conditions are applied). However if you start with MyModel::observe() the conditions aren't applied. In the HasEvents::observe() function a new instance of the model is created (MyModel in the example above). This fires off a sequence of boot events, including the boot event used by the trait BelongsToTenants. However, the $tenants collection it needs (from TenantManager) isn't filled yet, so it can't apply the tenant conditions to the global scope. The collection is filled later, once you call Landlord::addTenant() @hipsterjazzbo any ideas how to make this more robust? maybe adding an exception or something? |
That makes sense. I set |
Also happening here... Any ideas ? I would like to keep my tenants in the route middleware and the observers in the appserviceprovider as recommended ... |
.@pimski is totally right about what's happening there. I agree that this should be better handled, but I'm not aware of anything I can do from within a package context to force the order like that. The only solutions I've come up with (involving various ways to set the tenants at boot time) remove the ability to add tenant dynamically, which is important functionality for me. Ideas? |
An idea:
In applyTentantScopes() push a model to the deferredModels collection if the tenants haven't been set yet:
Finally, add a method to apply the global scope to the 'deferred models':
Bit of code duplication and a lengthy name... :) |
This solution works for me! |
Just spent the last few hours trying to figure out why my users were not scoped - eventually commented out my What is the chance of the fix/workaround for this being merged soon? Thanks :) |
Okay I've tagged a beta release with the contents of #66. Could everyone please have a go, and if there are no issues after a while I'll tidy it up a bit and push it stable. |
Hey team 👋 |
If I add a model observer to a model which belongs to a tenant (like https://laravel.com/docs/5.3/eloquent#observers) the tenant filter is getting ignored.
Listening to events works fine (https://laravel.com/docs/5.3/eloquent#events).
The text was updated successfully, but these errors were encountered: