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

21. Validating invitations

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

Because we're eventually going to be listing the invitations we've created along with the email address, a really important part of inserting team invites is that we don't end up with the same email address being invited twice. Now we could create a validation rule to make

00:15

sure that this is unique within this table but there's a slight catch. This should be unique but only for the current team. So we can invite say mabel at codecourse.com to one team but we can also invite her to

00:30

another team as well. So her email address will be listed twice in the team invites table but our job is to make sure that they both work for different teams or they're both added only for different teams. Okay let's go

00:44

ahead and write a test out for this first just to check this and then we'll go ahead and fill this in. So we're going to say it fails to create invite if email already used or if the person has already been invited however you want to go ahead and write this

01:01

out. Okay let's go ahead and create out the user who's going to be doing the inviting and let's go ahead and pre-create an invite in the database. So let's use the team invite model and we'll use a factory on this to create out

01:17

this for the team id and we'll set that to the current team for that user so we're already creating it out and let's assign that to a variable so we can use it a little bit later on and let's set that to mabel at codecourse.com.

01:34

Now we haven't set up our team invite factory yet so let's just go over to that factory and all we really need in here is the token so let's go ahead and use string random and 30 directly in there. Okay let's go ahead and run this test directly just

01:51

so we can focus on this let's say pest and filter and we'll filter it to that name and let's have a look. Okay yeah so it did work obviously it's just risky because we're not making any assertions so acting as the user who is doing the inviting

02:06

let's post through to that root so team invites and store passing in the user's current team as the team that we're inviting to let's pass down the same email address that an invite already exists for on that team

02:24

let's say email and what do we want to do we want to assert this is invalid so we can either use invalid or we can check specifically for a session status error for that particular thing. Okay let's go ahead and run this again and it fails

02:40

of course because we get a true so it is valid this is allowed to happen and we would end up with a duplicate over in the database which is not great so where do we go for this well of course we go over to our team invite store request and we can just add on another validation

02:57

rule inside of our list of validation rules so let's change these into an array just to make this a little bit tidier and we'll set that max of 255 again but this time we're going to add in a specific unique validation rule with some conditions

03:16

so if we say something like this rule unique make sure we pull that in as well from illuminate validation rule so we're going to say rule unique and this is going to be on the team invite table which we can just reference the full

03:31

class for and it will be under the email address so if we did that that is going to pass our test so let's go ahead and rerun this and you can see we get green so great sounds like we've solved the problem the only problem is this now makes this

03:46

unique to that table without scoping this to the team so we could have Mabel invited to one team but then she wouldn't be be able to be invited to any other team now because of this validation rule so to get around this let's go ahead and write another test which verifies

04:03

that we can use the same email twice only if it's for another team so let's go and pretty much just take this entire test just so we don't spend too much time with the boilerplate over and over again and let's go ahead and say create

04:21

invite if email already invited to another team so basically we want to be able to already have this but we want to make sure she can be invited again and have that same email address in the database but for another team let's do this in a slightly different way

04:41

so let's get rid of the team id here and let's instead say four so let's say four team factory so that's a new team that we're creating aside from this one here so she's been invited to another team now and let's just make

05:02

sure over on team invite we add in this relationship so let's say what team this belongs to which is just a simple belongs to relationship on that team and now we can go ahead and act as that user invite them to our team they're already

05:20

invited to another team with the same email address and we should assert that this is valid like so okay let's go ahead and run this entire controller so let's say test and test feature team invite controller and

05:36

sure enough that fails yeah let's just make sure we pull in the namespace for that and let's try it again okay yeah so it's failed because the email address has already been taken but that shouldn't be the case she's been invited to another team but

05:52

because of our rule we're only allowing this table to contain unique email addresses which doesn't really make sense because multiple people can be invited to multiple teams so with a unique rule we can actually add in a where clause on this so we could check

06:08

that the team id equals or we could have this as a condition where this equals the team id that we've passed through into our request remember over on our team invite controller we get the team in here so this basically ensures that we can

06:23

store the same email address in the table but only for different teams okay let's go ahead and run our tests on this and we get green great so we know that we can invite multiple email addresses or the same email address now to multiple teams

Episode summary

In this episode, we tackle a common issue with inviting users to teams: making sure the same email address can't be invited twice to the same team, while still allowing someone to be invited to multiple different teams.

We start by writing a test to ensure that an invite can't be created if the email address has already been used for the current team. We use factories to set up our test data, including pre-creating an invite, and then run our test to verify that things are behaving as expected.

Initially, we add a "unique" validation rule for the email, but quickly run into a snag — this rule makes email addresses unique across the whole table, which isn't what we want. That means someone couldn't be invited to more than one team with the same email, which breaks our desired functionality.

To fix this, we adjust our validation so the uniqueness of the email is scoped only to the team. We also write a complementary test to check that the same email can be used for a different team. After updating our rule to enforce uniqueness for the email within the context of a specific team, we rerun our tests and confirm everything works as it should.

So by the end of this episode, our invites are correctly validated: no double invites to the same team, but the same email can be invited to as many different teams as needed.

Episode discussion

No comments, yet. Be the first!