fix: Honour a morph class in role lookups - #23
Conversation
Role lookups compared a polymorphic column against the configured class name, so a host that points the package at a subclass has to store that subclass name in every row. A host with rows already written under the base name, or one that registers a morph map, matches nothing and sees no workspaces and no members. The comparisons now ask the model through getMorphClass, which answers with the class name unless the host says otherwise, so what is stored today keeps working and an override or a morph map is honoured as well.
Code Review Summary✨ Role lookups stop comparing a polymorphic |
![sourceant[bot]](https://avatars.githubusercontent.com/in/1161781?s=60&v=4){kind=small}
A role assignment is written through the user's own morph relation, so the user side of the member lookup holds whatever that answers. Comparing it against the configured class instead returned no members for a host that maps its user model, while the same host's inverse lookup worked. Both sides of the lookup now ask the model, and the controller uses the workspace it already holds rather than resolving the name a second time.
1 participant
Role lookups compared a polymorphic column against the configured class name, so a host pointing the package at a subclass has to store that subclass name in every row. A host with rows already written under the base name, or one registering a morph map, matches nothing: no workspaces, no members.
Nine comparisons now ask the model through
getMorphClass. It answers with the class name unless the host says otherwise, so existing behaviour is unchanged and an override or a morph map is honoured as well.The three places that need a class to instantiate, the route model binding and the two relation definitions, still use the configured class.