Inconsistent behavior with relatableQueryUsing() accessing model fields

[rpungello]

• Laravel Version: 10.34.2
• Nova Version: 4.32.6
• PHP Version: 8.2.13
• Database Driver & Version: MariaDB 10.11.4

Description:

We have a multi-tenant application, so within Nova we'd like for various fields to only pull from data belonging to the same company as the resource we're editing.

To do this, I have tried the following in our Nova Product resource. Product models have a distributor_id property that defines which company they're for.

BelongsTo::make('Default Type', 'defaultSampleType', SampleType::class)
    ->relatableQueryUsing(function (NovaRequest $request, Builder $query) {
        Log::debug("ID: $this->distributor_id");
        $query->where('distributor_id', '=', $this->distributor_id);
    })
    ->nullable()
    ->hideFromIndex(),

When I load the Product resource within Nova, three log entries are written, but nothing displays in the drop-down for "Default Type"

local.DEBUG: ID: 128
local.DEBUG: ID: 128
local.DEBUG: ID:

It seems like, for whatever reason, on the final load all the model properties are missing, which results in the menu checking for a null ID instead of the actual ID. The documentation for relatableQueryUsing() unfortunately only uses static data, so perhaps I'm just using this feature incorrectly, but the documentation makes no mention of how to factor in model properties so I was forced to guess.

I was able to make this work by using the following, but this results in an extra database query that shouldn't be necessary based on my understanding of how Nova handles model properties.

BelongsTo::make('Default Type', 'defaultSampleType', SampleType::class)
    ->relatableQueryUsing(function (NovaRequest $request, Builder $query) {
        $query->where('distributor_id', '=', ProductModel::whereId($request->resourceId)->value('distributor_id'));
    })
    ->nullable()
    ->hideFromIndex(),

Detailed steps to reproduce the issue on a fresh Nova installation:

[crynobone]

There are request that will create a new instance of Resource without fetching the model and this would make $this->distributor_id to be null.

[rpungello]

This is happening when I edit an existing model in question though, not a new one. This model already has a distributor_id of 128, but when I call up the edit page, the drop-down for sample type doesn’t work properly. If I hard code it to 128 instead of $this->distributor_id, it works as expected and displays sample types for distributor_id 128

[davidhemphill]

Even if you're editing an existing resource, there are times Nova pulls the fields with a fresh nonexistent resource. So logging there may lead to false positives.

In your application, would it be more convenient to apply this query scope globally for every Nova request?

[rpungello]

There are times we'd want all records to display, so a global-level filter for the model/Nova resource wouldn't work.
It seems like the method I was using should work, based on the fact that it does if a hard-code the number, it just seems like it's using the wrong call to populate the drop-down.

[vesper8]

I was able to make it work like this

                ->relatableQueryUsing(function (NovaRequest $request, Builder $query) {
                    if($request->has('resourceId')) {
                        return $query->where('some_id', MyModel::find($request->input('resourceId'))->some_id);
                    }
                })

[rpungello]

Yes, I was able to do something similar in my original post, but it seemed like that was an unnecessary database query when, based on testing, it should work the way I originally tried it. It's just Nova is making multiple requests to load the drop-down, only some of which correctly have all the model fields defined. If it used the call that has all the model fields defined, it would work.