In the previous episode, we implemented a ticket filtering system, and it works very well. We can filter tickets based upon all of its attributes, the status, the title, created_at, and updated_at. But one of the things we didn't do is provide the ability to filter based upon the author of the ticket. So that if we wanted to get all of the tickets by a particular author, you know, we could do that. And it's perfectly acceptable to want that functionality. However, I don't think we should be doing that through the tickets.

And it's perfectly acceptable to want that functionality. However, I don't think we should be doing that through the tickets. Because if we have the userID, then we already know who that user is, and we should be going through the user endpoint. Because yes, we can include the tickets for a given user. But of course, that's just including the tickets with the user payload. What if we did something like this, to where we could specify a specific user, and then have another segment that says tickets. That way, we would get the tickets just for that user, and then we could use our ticket filtering system to filter those tickets from there.

That way, we would get the tickets just for that User, and then we could use our ticket filtering system to filter those tickets from there. That makes the most sense to me. So let's do it. We are going to be redoing some things though, however, because, you know, we've used this term User because, well, we have users in the database. But logically, we have really two types of users. Right now, we just have an author, but eventually, we will have the person that the ticket is assigned to. So we need to make that distinction, at least as far as our controllers and all of our stuff.

assigned to. So we need to make that distinction, at least as far as our controllers and all of our stuff is concerned. So we're going to make some changes. First of all, let's go to our routes, because that's really the first place that we need to go. So api/view1, and instead of users, we are going to say authors, and we're going to change our UsersController to AuthorsController. So we just need to make those changes first, and that means we will need to go to our UserController so that we can change its name.

So we just need to make those changes first, and that means we will need to go to our UserController so that we can change its name. And if we're going to change its name, we might as well change its file name as well. So we'll get that done. Now inside of our new AuthorsController, we need to change this. It's still a User, but we're going to change the parameter name to author instead of user, make the necessary changes there. We'll worry about the update and all of that stuff later on. Right now, we're just focusing on what we are working with at this point in time. And then from here, we need to go to our resource classes.

Right now, we're just focusing on what we are working with at this point in time. And then from here, we need to go to our resource classes. So let's go to our UserResource, and instead of this route is users.star, we want authors.star. We'll need to change basically everything where we use that, but that's it. Let's go to our TicketResource, because we have one use here, and that should be it. So let's do a sanity check. Let's make a request for our User. We need to change the URL to authors, and we don't have the tickets stuff yet. So let's send that request, we get our users, we're good to go. So let's move on now that we have made those changes.

So let's send that request, we get our users, we're good to go. So let's move on now that we have made those changes. And we are going to create a new controller, and it's called a nested resource controller. So the idea is that our main resource is authors, and we are showing an individual author, but then we want to show some child information, like the tickets. The tickets are a child of the author. So we will create a nested resource controller to where this is, of course, going to be API V1. But then the controller name will be AuthorTicketsController. And we can specify resource and all that stuff, but I'm just going to create just a normal empty controller there.

And I guess we should do AuthorTicketsController. And we can specify resource and all that stuff, but I'm just going to create just a normal empty controller there. And let's go back to our routes, because we need to add our routes here. And it's going to look like this. We're going to have authors.tickets, once again, the parent-child relationship. And then, of course, the name here will be authorTicketController. And there we go as far as that is concerned. So now we can go to our AuthorTicketsController, and we will have this index method. This is, of course, going to show all of the tickets for the given author ID. So we will get that as the argument, so that then we can return and we can use our TicketResource,

This is, of course, going to show all of the tickets for the given authorID. So we will get that as the argument, so that then we can return and we can use our TicketResource, because we are still working with the TicketResource here. It's just that we are working with a subset of those tickets based upon the authorID. So we will have our collection, and then we will use our Ticket model. And for right now, let's just say where the userID is equal to the authorID. And then we want to paginate those results. So if we take a look at this now, we are going to see that we have our tickets. We have our data. We see the tickets.

We have our data. We see the tickets. They are all formatted how they are supposed to be. We have all of the information that we would need. And aside from the URL, I mean, really, this is exactly like what we have as far as our normal tickets are concerned, except that, of course, this is a subset. These are all based upon the authorId of, well, in this case, five. But here's the beautiful thing about this. Since we already have our ticketing system all set up and ready to go, we can still get our ticket filter here as our filters.

Since we already have our ticketing system all set up and ready to go, we can still get our ticket filter here as our filters. And we can still call our ticket filters. But really, we don't want to do that. We want to call where, and then we want our filters. And all of that should work just like it did before. Although, let's put this on multiple lines so that it's all nice and pretty. So let's go back to Postman. Let's use some of our filters. So we want only the completed tickets.

Let's use some of our filters. So we want only the completed tickets. So we will filter based upon the status. The status code is C. So call to undefined method filters. Yes, because it is filter, isn't it? It's not filters. So with that, there we go. We have our tickets that were all written by the User with an ID of 1, and the status is all completed.

We have our tickets that were all written by the User with an ID of 1, and the status is all completed. Looks like there was just one. Okay, so let's include canceled tickets as well, because I want some verification that it's still working. And yes, it is. Okay, so we are able to see that we get both the completed and the canceled tickets. And so now that we have the ability to filter our tickets, both for a specific User and just in general, I want to add the ability to sort data. And we will look at how in the next episode.

a specific user and just in general, I want to add the ability to sort data. And we will look at how in the next episode.