The has many through relationship is one of those relationships that we don't use all of the time. But it's very useful when we do need to use it. Like imagine that we will have a department and a department will have many users and because users have tasks, we could say that a department has many tasks. But the only way that that relationship works is if we go through the users has many through. So we essentially start with one model or one entity

through the users has many through. So we essentially start with one model or one entity and we access an unrelated model through a model that actually has a relationship between those two things. Makes sense. Hopefully it does. So we're gonna start by creating a model. We're gonna call it department and we need a migration in a factory. Uh, let's go ahead and also create a migration because if we are going to set up a relationship

Uh, let's go ahead and also create a migration because if we are going to set up a relationship between a department and a user, well we need to modify the user's table because we need to add a department ID to the user's table. And for right now, that's all that we need to do. So let's open up the department migration. Let's also open up the ad department ID migration. We'll start with the departments

Let's also open up the ad department ID migration. We'll start with the departments because this is gonna be easy. All we need is really a name for the department. So we will add that as a string and we are good to go there. But for our user's table, this is gonna be a little bit different because now we need a foreign key that matches a particular department. So our foreign ID is for the department id.

that matches a particular department. So our foreign ID is for the department id. But let's think about this. You know, a user doesn't necessarily have to be assigned to a department. So that would mean that this relationship or this foreign key could be knowable. And if it's knowable, then well, if we delete a department, we don't necessarily want to delete all of the users of that department.

we don't necessarily want to delete all of the users of that department. So we would essentially want to set the department ID back to null. But before we do that, we do want to call constrained because we do want that referential integrity. We want a department to exist before we can assign a user to it, but then we will call null on delete so that if we do delete a department,

but then we will call null on delete so that if we do delete a department, we just null the department ID for the user and that's gonna work there. So let's open up the user model and let's add our relationship here so that we have a relationship with a single department. So this means that this is a belongs to relationship and we want to return this belongs to and the department is what we have a relationship with.

and we want to return this belongs to and the department is what we have a relationship with. So that's all that we need to do for our user model. But let's open up the department model and let's add the protected fillable and the name field. Let's also set up the user's relationship. And this is a has many relationship and once again we'll simply return. This has many users

and once again we'll simply return. This has many users and that sets up that relationship. But now we also need to set up a relationship to the tasks and remember that this isn't a direct relationship, this is a relationship through the user model. So that only makes a difference here because we are going to return A has many through relationship as far as the name of this method. It's gonna look like any other kind of relationship

through relationship as far as the name of this method. It's gonna look like any other kind of relationship that we have done so far. And then we will return. This has many through, but then we need to specify what this is a relationship with. Well, it's gonna be for our task, but that's not good enough because there is no direct relationship between the department and the task.

because there is no direct relationship between the department and the task. We have to go through the user model to get to that relationship. So this is the main difference here. We return has many through and the has many through method is where we define the relationship to the unrelated model task through the model that we have a relationship with the user. So with that done, we have everything set up.

through the model that we have a relationship with the user. So with that done, we have everything set up. We just need to go to our department factory. So let's do that so that we can easily create these things and we will use faker to uh, I guess let's use the company method. And then from there we just need to open up the database cedar so that we can, you know, seed our database and we can kind of do something similar to the teams to

seed our database and we can kind of do something similar to the teams to where we can create some departments using the factory. Let's just create three departments and then from there we need to include the departments here in our use statement. So that then let's see, let's pick a random department using our departments and we'll just call random so that then we assign our teams.

and we'll just call random so that then we assign our teams. Then we can do this in a couple of different ways. Let's do it from the idea from the department. So that's we will add to our users by saving the user that we are currently working with. And there we go. So that should work. We'll see. Let's migrate our database with migrate fresh seed. Hopefully everything is gonna run just fine and it does.

with migrate fresh seed. Hopefully everything is gonna run just fine and it does. So now we just need to use this relationship. You know, we could create a controller in all of that stuff. I don't see any need to, because this will be pretty simple. So we are going to get our departments and let's do this. Let's get our departments, let's also get the tasks for those departments so that we can list the departments and the tasks. We don't necessarily need to display the users,

the departments and the tasks. We don't necessarily need to display the users, although realistically we would, although I guess we could include the users because you know, we could list the department and then the task and we could say that it's assigned to a given user. So let's do that. So we'll have our departments to where we will get our departments with the tasks

So we'll have our departments to where we will get our departments with the tasks and the users and we just want to get them all so that then we will return a view called departments index. And then for the model we will compact the departments. Okay? So that way we will be able to work with both tasks and users inside of our view. Now I don't have this view, so let's create one.

and users inside of our view. Now I don't have this view, so let's create one. Let's go to resources, views. And we are going to create a new file inside of departments, call it index blade PHP. So first we want to extend layouts app so that we have a layout page and we also have a content section. So let's end that section as well so that then I can just paste in this markup.

So let's end that section as well so that then I can just paste in this markup. Now this is going to display multiple tables for every department. We have a table and the tasks. So let's first of all output the department name. And you know what, let's do this. It could be entirely possible that a department doesn't have tasks. So let's check if the department

that a department doesn't have tasks. So let's check if the department tasks is empty. Well then we don't want to display a message. We could just have a P element. Let's make the text Gray 400 and we could say that no tasks are assigned to this department. That'll be fine. So that then if we do have tasks, we display our table.

That'll be fine. So that then if we do have tasks, we display our table. So we need an end if there, so that's, we have our table head to where we display the task, the status and who it was assigned to. And then we have our table body so that here we can iterate over the department tasks as a task. And then we just need to output the row. So we'll have our TR element

And then we just need to output the row. So we'll have our TR element and then let's have our table cell, which will have horizontal padding of four, vertical padding of two. And we want three cells with that same styling. So let's paste that a couple of times so that then we can output the task title. I think it was title. I'm not sure if we used title or name, but I guess we're gonna find out.

I think it was title. I'm not sure if we used title or name, but I guess we're gonna find out. Then we have the status of that task, but then we also want to know who the task is assigned to. So we will access the user so that we can get the user's name and that should be that. So now we can go to the browser and we can just go to departments and we should see our list of departments.

and we can just go to departments and we should see our list of departments. Our, our table looks completely different than it did before, but we can see that we have this department and it has all of these tasks. They have various statuses and they are assigned to just a couple of people. We can keep scrolling down to view all of the departments and we, we only have three departments, so we should only see three.

and we, we only have three departments, so we should only see three. Yep, that that is the case. So we are able to display all of the tasks of a given department by going through the user relationship. But just like every other kind of relationship, we can actually query a has many through relationship. Like for example, let's say that we wanted to get only the completed tasks for a given department.

Like for example, let's say that we wanted to get only the completed tasks for a given department. So let's add another route for department and we'll just get the first department. We'll make it easy on ourselves so that then we want to get just the completed tasks. Well, that's gonna be easy enough to do because we will use our department to access the tasks relationship so that we can get where the status is C for completed.

to access the tasks relationship so that we can get where the status is C for completed. Then we would just get those tasks and voila, we have the completed tasks for that given department. We don't have to specify users or anything like that. The has many relationship that is returned by the tasks method is going to handle all of that for us. So if we wanted to just output this as Jason, we could simply return completed

So if we wanted to just output this as Jason, we could simply return completed and then we could take a look at this in the browser. We'll just go to slash department instead of departments and voila, we have all of the completed tasks for the given department. And that's the has many through relationship. It's a clean and elegant way to reach across multiple relationships. In our case, we moved from departments to tasks

to reach across multiple relationships. In our case, we moved from departments to tasks to completely unrelated things, but we moved through the users to get the tasks for a given department. So if you ever catch yourself writing a bunch of nested loops or writing complex joins to dig through related models, then you might want to reach for the has many through relationship.

then you might want to reach for the has many through relationship. It's one of eloquence little gems that we often forget about.