Sign in Get started

This episode is for members only

Sign up to access "Laravel Teams" right now.

Already a member? Sign in to continue

Playing

35. Getting related models through teams

Episodes

0%

Your progress

Total: 4h 36m
Played: 0m
Remaining: 4h 36m

Join or sign in to track your progress

01. Introduction and demo

02. Setup with Pest

03. Building the user teams relations

04. Creating a personal team when registering

05. Leaving all teams when an account is deleted

06. Tracking the current team

07. Showing team details in the UI

08. Switching to another team

09. Authorising team switching

10. Updating a team name

11. Basic roles and permissions setup

12. Team roles and permissions middleware

13. Authorising current team updates

14. Testing team permissions through HTTP requests

15. Leaving a team

16. Displaying team members

17. Making team members look better

18. Removing a team member

19. Preventing self removal from a team

20. Storing invitations

21. Validating invitations

22. Authorising team invitation creation

23. Displaying invitations

24. Revoking invitations

25. Sending an invitation email

26. Accepting an invitation

27. Displaying a modal to change a member’s role

28. Updating a member’s role

29. More authorisation and checks for role changing

30. Fixing up the email sending test details

31. Fixing and validating email addresses for invites

32. Tidying up @can directive checks

33. Detaching roles when removing users

34. Adding an extra layer of protection to the team middleware

35. Getting related models through teams

36. Building a helper to access the current team

37. Getting all related models through all teams

38. Creating new teams

Transcript

00:00

Over the next few episodes we're going to work on getting related models through teams. First of all let's go ahead and just list out a let's say a list of projects on the dashboard that belong to the current team that we are in. So I expect to see projects for the Alex team on the dashboard here and if I were to switch over to another team I would see a completely different

00:21

list of projects assigned to that team and obviously we're using the example of projects here but you could do this for absolutely any model. What we'll then do is go on in the next couple of episodes and just make this easier to work with as well as listing models for all of the teams that we belong to in one place which involves a slightly more complex relationship.

00:43

Okay let's go over to our project and start to build this model out. So let's make out a model called project and of course we'll create a migration and a factory alongside of that as well. Okay so let's open up the create projects table and let's again just keep this really simple. Who does a project belong to? Well there's a couple of ways that you could think about this.

01:04

Obviously it's going to belong to a team so we're always going to have a foreign id in there that belongs to a team and we can go ahead and constrain that to the teams table as well. It will have just general information about this so I'm just going to add a string in here for a title for the project. What you could also do is you could assign this to a user as well but that

01:25

would be more like the owner id so you could say something like owner id and then constrain this to the users table. We're not going to do that because it really depends on what you are adding to your application. We'll just keep it super simple for now and you can go ahead and add anything that you need. Okay let's go ahead and run our migrations here to get this in the database

01:46

and just while we're here let's go over to our project factory and just fill in a definition for a title here. So let's say fake sentence and we'll just do three words for that. Okay so now that we've got this done the relationship here is pretty simple between a team and a project. It's just a has many so let's go ahead and create out a projects relationship inside of here and this is

02:11

just going to be a has many relationship to the projects that exist for this team specifically and we know that we can already get the current team for the user which will return a team object so we can get the projects for the team that the user is currently within. So this is going to be pretty straightforward but like I said we'll expand on it. Okay now that we've got this

02:35

relationship let's go ahead and create out some fake records in the database to get this working so let's go ahead and run phpr and tinker here and let's reference app models and project let's grab the factory instance for that let's create out three projects for this user and we'll create these but in the context of the team id that we want to see. So if we hop over to the database

03:00

let's do this for the team that I'm currently in which is 17 and there we go great so we should now have a few projects for that team. Okay now that we've done that let's go over to our web routes here currently our dashboard is not within a controller so I'm actually going to go ahead and create one out here just to keep things nice and tidy so let's create a dashboard controller out

03:20

in here let's go ahead and switch this over so let's get rid of this and change this over to our dashboard controller and we'll make this invocable let's go ahead and pull that down as well so over in our dashboard controller now we just need an invoke magic method in here so let's say invoke and we want to return that view like we had in that root closure but now we want to

03:46

pass down all of the projects for this particular team so for this let's bring in the request because we need to access the currently authenticated user to output these projects we're going to go ahead and access that user then we're going to access the current team and then from that current team we're going to grab all of the projects we're going to shorten

04:08

this down a little bit later so it's more convenient to access but for now let's head over to our dashboard.blade.php file and we'll just go ahead and output this so why don't we grab a header here from team edit and it'll be absolutely fine and let's go ahead and say projects let's create a container down here with a class on the top of margin six and let's do a for each on all

04:32

of the projects so let's say for each project as project and in here let's just output the project title and we should be good let's just fix that up okay let's go over and there we go we've got three projects now of course you could write a test for this to make sure that the projects that you're passing down are correct we already kind of know how to do this let's just head over to

04:55

Mable's account really quickly over to the dashboard you can see that there are no projects so we know that this is scoped to the current team and no one else should be able to see this information okay now this is all well and good but over in our dashboard controller or in fact anywhere else that we need to grab the projects for this team it would kind of make sense to

05:16

create a helper for this since accessing the current team through the user through the request or using the auth function or auth facade is going to get really annoying having to type this out every single time so let's look at a way that we can create a helper for this in the next episode and we will be writing tests for that

Episode summary

In this episode, we kick off a new mini-series all about working with related models through teams in our Laravel app. We're starting simple: the goal here is to list projects on our dashboard that belong to the team we're currently viewing. When you switch teams, you should see a totally different set of projects. While we're focusing on projects as our example, you could easily adapt everything here to other related models too.

We start by setting up a new Project model (plus migration and factory), making sure projects belong to a team via a foreign key. We also keep things clean and simple in the migration—just a title and the team_id for now. Once that's set, we use the factory to bang out a few fake projects in the database for our demo team.

Then, we move over to structuring our controller properly by introducing a new DashboardController. In it, we fetch all projects for the current team and pass them down to the dashboard view. On the frontend, we loop over each project and display its title.

We double-check that project visibility is working as intended by logging in as another user (with a different team) and confirming they see only their team's projects—so the scoping is working!

To keep things tidy, we wrap up by mentioning that, in the next episode, we’ll create a convenient helper to avoid repeating ourselves every time we need to grab a team's projects. We'll also get into some tests to make sure everything is solid.

Episode discussion

No comments, yet. Be the first!