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

06. Tracking the current team

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

We might be getting ahead of ourselves here, but let's consider how we're going to track which team the current user is within. So imagine that we have a drop down here with a list of teams that we currently belong to. When I click on one of them, I want to set this somewhere so that within the application, we always know which team we're a part of. And then each of them teams are going to have their own resources like projects or whatever you want to add to your teams.

00:25

So let's figure this out in the database and we'll write a quick test for this just to verify this, because when we go ahead and create an account, we want to set our current team to the personal team that was created. OK, so let's start out with a migration here. So let's make out a migration and we'll call this add current team ID to users table.

00:45

That's going to be the column name that we'll use. So let's say add current team ID to users table and let's fill this in. So this is going to be a foreign ID that, of course, references a team that's a current team ID. We're going to make this nullable because when we first create an account, this won't be filled.

01:04

And then let's constrain this to the teams table. OK, let's go ahead and migrate these changes. And we should be good, so let's hop over to the database and there we go, we've got a current team ID. Now, when we create an account, we want this to be filled with the current team that we're in.

01:23

So let's hop over to our user observer test and let's make sure that this is the case. So let's say it sets the current team to the personal team or whatever we want to say. And let's check that this is the case. OK, so we'll start things out by just creating out a user.

01:42

So let's go and say user factory and create. We could pass a name in here so we can check that the current user's team is actually the team that we have created as part of this personal team creation. So let's just give that a name of Alex as well. And what we want to expect here is that the user's current team ID is equal to or to be the user's team's, the first team's ID.

02:17

So basically, this is the first team that gets created, which is our personal team when we create this out. And we want to make sure that the current ID matches. Now, this is not going to be the case at the moment. Obviously, that's going to fail because null is identical to one.

02:32

So let's hop over to our user observer and let's fill this in here. So effectively, what we want to do is just update this user. So let's go ahead and set the current team ID to the team ID that we have created just here. We'll do this slightly differently in a second when we introduce a current team method on the user.

02:52

And then we just want to go ahead and say user save. So we'll come back to this and refactor this because I don't really like doing things like this. OK, so once again, this is probably going to fail just because of our fillable field. So let's go ahead and just make this guarded false or we could set guarded with just an ID.

03:10

It's entirely up to you, but I tend to just say false. And let's go ahead and run this test and see what happens. OK, great. So that works. Now, eventually, what we're going to need over on our user model is a method to grab the current team out.

03:24

We're not going to directly test this because it's going to be part of a lot of what we're creating. So let's create our method called current team that will basically just grab the team that we have currently selected. So for this, we're going to create a belongs to relationship. So let's say this belongs to and this is going to belong to the team model so we can extract an actual team back.

03:48

But because we're not using the standard columns that we would usually use within Laravel, we're just going to need to specify this as the second argument. OK, so now let's update our user observer. Instead of doing this, we're going to say current team and then we're going to associate this with the personal team that we've just created.

04:06

And that does pretty much exactly the same thing. Before we go ahead and save it, it's just a little bit cleaner. OK, let's go ahead and run our tests and see what happens. And yeah, sure enough, we get green.

04:16

So we now know that this will set the current user ID or current team ID when the user gets created. OK, let's hop over to the database and just verify this. I'm going to get rid of the user here that we're going to have to get rid of this relation, this team and this user. And let's go over and just create a new account.

04:33

So we'll head over to register here. Let's go and check this out and see what happens. And when we hit register, that should create our personal team for us and it should set the current team ID to the ID of that team. Great.

Episode summary

In this episode, we start laying the foundation for how the app will keep track of which team a user is currently working with. Imagine having a dropdown in your app listing all the teams you belong to – when you pick one, we want the app to remember and use that choice everywhere. Since each team can have its own projects and resources, tying everything to the current team is super important.

To set things up, we add a new current_team_id column to the users table through a migration. This column points to the team that the user is currently active in, and it's nullable so it doesn't break anything at the start. We make sure it's a foreign key referencing the teams table, to keep things in sync.

Next, we write a test to ensure when a new user is created, their current_team_id gets set to their "personal team" right away. After some initial failures, we fix the fillable settings and make sure our code properly sets this field via a relationship on the user model, refining things so it's clean and reusable.

In the end, we confirm with tests and a quick manual database check: new users have their current team set up perfectly from the moment they register. This paves the way for more flexible team switching and resource management as we keep building.

Episode discussion

No comments, yet. Be the first!