BelongsToMany: Multi-Select and Relation Managers

That is true, and I do like (and miss) some of the hand-holding sometimes, but Povilas did mention that the pivot tables would not be his emphasis topic of this lesson. Probably many ways to do it, but I just added the migration:

php artisan make:migration create_product_tag

then added the middle columns like so (there are other ways):

Schema::create('product_tag', function (Blueprint $table) { $table->id(); $table->foreignId('product_id'); $table->foreignId('tag_id'); $table->timestamps(); });

Add the relationships in the models (in Product.php add):

public function tags(): BelongsToMany { return $this->belongsToMany(Tag::class); }

add the inverse in Tag.php :

public function products(): BelongsToMany { return $this->belongsToMany(Product::class); }

Some sample data in the intermediary (pivot) table, and it worked fine.

Thanks @johnogle to provide this instruction.

@PBTraining, I've just added the "use BelongsToMany" line of code. But, as Johnogle said, in this course I'm not hand-holding for the Laravel part, as Filament is a tool ON TOP of Laravel, which implies that you already have the relationships/tables set up. The course is already quite long even without the Laravel part, and if something is not working for you, feel free to ask questions in the comments.

As always - great tutorial Povilas, thank you. And i like the text format, i think for this type of tutorials it's the best.

As for Laravel part, I would also prefer at least to see a mention of required pivot table and similar things. It's not too many extra lines of text and code, but would totally make it clear what we're working with.

I think that instead of literal hand-holding, it would be better just to give instructions as a list on what is required to move forward. So, something like:

1. Make a Tag model with migration and seed data
2. Create a pivot table so that a product can have many tags
3. Update the Tag and Product models with the relevant relationships

As a bonus, it'd be nice for there to be links either to other courses or to the Laravel docs so that people can go off and fill in gaps / refresh their knowledge and then continue.

The only thing I found a bit disruptive to learning was the fact that I wasn't specifically told what I needed to do to prepare for the lesson. So then part way through, I was kinda thinking, "hmm.. I'm going to need a pivot table here"

I definitely agree with the idea of not adding lots of extra details about how to do this though as it's out of scope. But a few signposts would be nice I think :-)

same question

I think it is loaded when you start typing the first symbols then it's auto-completing it. You can enable/disable that behavior with ->searchable() from what I remember. Take a look at the docs for all Select options.

Thanks for an answer, I found solution in documentation, for this you can just do preload() method, in place where using multiple()

Chain ->preloadRecordSelect() method to Tables\Actions\AttachAction::make()

// ...
->headerActions([
    Tables\Actions\CreateAction::make(),
    Tables\Actions\AttachAction::make()
        ->preloadRecordSelect(),
    ])
// ...

Sorry, I don't exactly understand what you mean. Maybe show some demo or something.

Ooooh think I found a video on it... but it uses the relation manager (option 2). That will complicate things but meh, if it works I guess. https://www.youtube.com/watch?v=ERbpyZF8G5M

Single attaching is a PITA and not really what I am after. I'd much rather just have a simple multi select field and year field in the main form but I can't seem to get that to work.

This feature is documented under relation managers https://filamentphp.com/docs/3.x/panels/resources/relation-managers#sharing-a-resources-form-and-table-with-a-relation-manager and Povilas made a youtube video about it today https://www.youtube.com/watch?v=gHKin-a7mPY

thank you

Hi, there are a few ways to do that.

1. Using an observer - Automatically add the missing ID on saving event
2. Using afterSave() on your create/edit form: https://filamentphp.com/docs/3.x/panels/resources/relation-managers#importing-related-records

Both ways will check for a specific event to happen and then add the data you need to the model

Thanks, Modestas, this is very helpful!

Try this:
Select::make('audit_id')
->relationship('MODEL_RELATION_NAME', 'FIELD_NAME_TO_DISPLAY')
->label('Client')
->options(AuditSchedule::with('audit.clientCertType.client')->get()->pluck('audit.clientCertType.client.client_name', 'id'))
->searchable()\

An example of one of mine:
Select::make('discipline_id')->relationship('discipline', 'name')->searchable()->preload()->required(),

I don't think all our headers are so important and clear so people would link to them. For some of them, yes, but if we make it in all headers for all lessons in all courses, it would not make much sense.

You can create a custom view for this and display whatever is needed inside

You mean something similar to Creating CRM with Filament 3: Step-By-Step -> Creating Tags for Customers ?? Good idea, I haven't thought to do like this, i believed there was an easiest way.. on the query level

Yes, pretty much like that!

Of course, this can be done via query, but it's a bit too much to explain how. I can only give you a direction to use modifyQueryUsing() on the table itself, as anything else would require me to understand your database structure

First of all thank you for your answers (and sorry for my english "scolastic", but here in Italy we aren't so good as in other european countries!).

I solved the problem with a workaround: I created a new relationship on the User model:

public function currentMemberships(): HasMany
    {
        return $this->hasMany(Membership::class)
                            ->where('year',date('Y'));
    }

so I have a second relation with only the membership of the actual year and I used in the table instead of the normal memberships relation.

Just to let you know, the database has a normal User table, without strange "things", and a Membership table like this:

Schema::create('memberships', function (Blueprint $table) {
            $table->id();
                        $table->foreignIdFor('User::class');
            $table->year('year');
            $table->tinyInteger('type');    //Cast con ENUM
            $table->string('number');
            $table->timestamps();
        });

So I need in the users table to view only the users with a membership on the current year.

I don't know if my workaround is "elegant", but works, and it's reusable in other places!

This is actually a perfect workaround! This gives you more than just the table solution!

ps. Don't ever stress about your english - if we can understand you - it's GOOD! (we are also non-english speakers here :) )

Thanks a lot! You're a great team!!!

Hi laravel daily team! I disturb you with another problem, in the same I project:

I have races, and in every race a user could subscrive, but the price change as far is the race date (e.g. till 31/07 €10; from 01/08 to 31/08 € 15 etc..) So my idea is to create a tranches table, where I store expire date a cost, of corse a Race has many Tranches; and I think that Users and Tranches are connected with a many-to-many relationship (using pivot table). Here the db schema (just to explain easily): https://drawsql.app/teams/dr-capins/diagrams/teammanager

In theory everything works great, but in filament I have an Issue: I don't want to create a TrancheResurce (it doesn't make sense), so I manage tranches CRUD from RaceResource using a Relationship Manager (and it works correctly).

But now, how can I manage subscriptions to the race? The administrator needs to attach a user to the race (passing for one of the tranche model). Teorically I need a kind of belongsToManyThrough, because every race should have many users, but passing through the Tranche model. I really don't know hot to manage this in filament. Maybe with a page? But how?

The last resource for me is to change the db schema, connecting directly races, tranches and users in a 3-model-pivotTable, but I really dislike this solution, because the db will not be normalized anymore (in a pivot row of this table we will have user_id, race_id and tranche_id, but it's clear that race_id is redundant.

Do you think there should be a solution keeping the db schema? Is possible to "combine" to relationship? (I also look for the has-many-deep package of Stoudamire, but doesn't seems to be for my situation.

Thanks a lot for your attention.