How can I hide rows from a table based on a certain condition?

[red fjord]

If you have a record policy... that policy will be what sets if they can view that record?

[grizzled ridge]

It should, but the record appears normally in the table, what canView hides is the ViewAction

[fair mortar]

Shouldn't the logic be in the query itself if possible?
This way you know that the rows wont be in the table and you return less records from the database.

return $table
        ->modifyQueryUsing(fn(Builder $query) => $query->where('insert_condition'))

[grizzled ridge]

Yes, that would be infinitely better in terms of performance!

But here I need to check record by record in the policy if the user follows the necessary permissions to see that record

[fair mortar]

It all depends on the query needed. The condition should match the policy. Lets say that the policy to view the record is like you have in the img ($mailConfig->id === 1) in the condition you must have something like ->where('mailconfig.id','1'). Something like that but adapted to your case

or if its related to the user you can add ->where('user.id',Auth::id())

[red fjord]

You can scope the query to hide rows with X in absolutely if theres a lot.

[grizzled ridge]

No, I need a way to hide/show based on record, because this is global

[fair mortar]

ok, its global but whats the condition that you use to evaluate the policy?

[grizzled ridge]

Each record can have its own condition, this implementation is at application level

[fair mortar]

so you're gonna create a policy class for each record?

[grizzled ridge]

No, for each model, I misspoke, sorry

I'll clarify here.

Here's what's happening: I have an architecture based on modules that act like packages for the application, and I have a function called authorizeAction that checks whether the logged-in user has permission to access a specific action on a model through its policy.

I believed that, with canView being false, that line wouldn't appear for the user—but that's not the case. The canView only removes the ViewAction.

[fair mortar]

but how do you decide in the policy if the user has access to the other model?

[grizzled ridge]

What do you mean?

[fair mortar]

how do you know if the user has access to the model? Lets say a blog post, in the view policy the condition should be $user->id === $post->author_id or something like that

[grizzled ridge]

Oh right, since I’m the one creating the modules, the policy permissions are defined at the application level.

I’m responsible for developing the modules.

Let’s say my module “MegaReport” has a model called Report.

This module runs across multiple applications in the company, so the policies are defined at the application level. Imagine the following structure:

app  
database  
resources  
Modules / MegaReport

The policy will be implemented in:
app / Policies / MegaReport / ReportPolicy

And we handle having Laravel automatically discover the policy. This is fully functional for all features (ViewAny, Create, Update...).

So, as the module developer, I don’t need to know what conditions will be implemented in the policy.

[fair mortar]

I'm asking how/where do you define if the user with id 1 has or doesnt have access to report id 420

[mighty pond]

Just share the policy for view

[grizzled ridge]

In this case, it would be in the ReportPolicy, in the view method.

[fair mortar]

the code man

[mighty pond]

he is asking for the code

[grizzled ridge]

There's no code, it's not me who's going to implement it, I'm responsible for making the modules, that's at application level, The code can be a check if the user has an admin role, for example

[fair mortar]

then the person who's gonna implement the policy should be responsible for managing the filament resource. Because its based in the conditions that the filament operations are based. But the table query after the policy condition is defined should be easy to achieve

[grizzled ridge]

Okay, but that can't happen in my context. Ideally, the person working at the application level shouldn't modify a module's resources. The only tool available at the application level is the policy, and through it, they should be able to manage this.

I thought about creating a macro that applies some kind of filter to the table, would that be possible?

[fair mortar]

Don't know

[cloud pumice]

You should never use a policy for this, its a dumb idea. I am not saying you are dumb, but whatever silly rules your employer is using about codebase management are. How are you even going to handle pagination if you need to loop through each record to run the policy? Horribly inefficient, bad practice even outside of Filament

this is 100% the job for the query (scope), any other answer is objectively wrong

[grizzled ridge]

The policy was an example of how to apply logic on the application side to filter records. In the print here I managed to do what I needed to do

Now I'm going to implement the logic in the scope

I did a test implementation like this and it worked exactly as I needed it to

[cloud pumice]

That looks fine, what was the problem doing this before?

I hope you arent just gonna call the policy from the scope?

[grizzled ridge]

None, I just hadn't come up with an idea to make it viable

[cloud pumice]

Each policy should have a matching scope if you need to do something like this, that scope can be managed by the application dev instead of the module dev if you need that

but policies are pretty flawed for this reason and cannot be a single source of truth