تماشای این درس نیاز به اشتراک حرفه‌ای دارد.

Create Group-User Pivot0:00

Now that we have our groups, the only thing that we need to be able to do is assign User to our groups. So we'll make a new migration called create_group_user_table, because this is going to be a pivot table. Just like we used to assign permissions to groups, we will do the same thing to assign User to groups. So let's open up that create_group_user_table, and we just need two columns, because this is a pivot table. So first of all, we need the foreign IDs for the User, and we'll go ahead and do what we did in all of the others, which is on delete, we will cascade. And before that, let's define the group_id, and that's going to be just fine. So with that done, we can go ahead, we can execute this migration, and we are good to go there. So we can close that. But we need to go to our Group as well as the User models.

Add Model Relationships0:55

So we can close that. But we need to go to our Group as well as the User models. And this way, we will just copy what we have for permissions inside of Group, and we will just change this to users, and that's going to use the User class. Then we will essentially need to do the same thing inside of the User model, except that it needs to be called groups. Now, of course, we have all of this role stuff, and you might also be asking what is the difference between groups and roles, especially since they could be used in the same way. I mean, we could have taken our roles, and we could have used them as groups,

especially since they could be used in the same way. I mean, we could have taken our roles, and we could have used them as groups, which I guess would have been okay, but we were also kind of transitioning away from roles. So it made sense to just leave roles as they are. Logically, there's not much difference, except that roles are typically for roles, whereas groups are something so that you can assign users to groups and permissions to those groups. It's logical differences, but it doesn't matter. We have our groups set up here for our user. We will get rid of our roles later in this episode, but for right now, we're going to leave them in because I want to make sure that we are able to assign users to our groups.

Update Edit Form Data2:02

We will get rid of our roles later in this episode, but for right now, we're going to leave them in because I want to make sure that we are able to assign users to our groups. So we need the edit view for our users, and we need the UsersController. Because whenever we show the edit form, we are providing the user, the permissions, and we also need the groups. So just like what we did with permissions, we will retrieve all of the groups and provide them to the view here. So that whenever we update, well, let's come back to the update. Let's modify the edit view. And really, we just need to take what we did with the permissions.

Modify User Edit View2:41

Let's modify the edit view. And really, we just need to take what we did with the permissions. We'll copy all of that, and we'll just make it afterwards. So that, well, do we want to do that? I mean, because from a logical standpoint, from a UI standpoint, how do we want to do this? Because we essentially want to be able to assign users to groups, but we also want to be able to assign permissions to users. So we still want both permissions and users, but what do we want to prioritize? Do we want to put the groups first in the form so that we prioritize, hey, create a group if it looks like that you're going to need that functionality?

Do we want to put the groups first in the form so that we prioritize, hey, create a group if it looks like that you're going to need that functionality, which I guess, yeah, let's take that approach. So we'll leave permissions as second. This first thing, though, we will change from permissions to groups. And it's just going to be a few changes here and there. Otherwise, it's almost going to be exactly the same. There's just going to be a few little differences. Of course, our variable names are going to be different. And how we determine to display if a group is selected is going to be different.

Of course, our variable names are going to be different. And how we determine to display if a group is selected is going to be different. Instead, what we can do is groups contains, and then we will supply the group there, and that should work. Although I'm noticing here the error message was already set up as groups, which means down here, we need to set this to permissions. But other than that, I think that has taken care of everything. So we have groups, group, group, group, group, group, no permissions there, which means we can go back to the UserController, and we need to sync up the groups.

Sync Groups on Update4:21

which means we can go back to the UserController, and we need to sync up the groups. So we can take the userGroups. We don't want to detach. Instead, we want to sync the data coming from the request. Although I don't think I changed, yeah, we don't have a description for the group. We have a name for the group. Otherwise, everything else should be okay. So back in the browser, we can see article authors and off screen I created SystemAdministrator.

So back in the browser, we can see Article authors and off screen I created User that is a system administrator. So if we want to save that, let's see what happens. If we go back to the edits, we can see that that is selected. So we're good there. Let's also go to our author and let's assign the Article authors group to that User. Once again, let's check just to make sure, yes, that is still there. And I guess if we wanted to give them system administrator and

Remove Role-Based Code5:07

Once again, let's check just to make sure, yes, that is still there. And I guess if we wanted to give them system administrator and then decide to take them out of the system administrator group, all of that should work just fine. And yes, it does. So now that we are able to assign users to groups, we just need to clean up a little bit. We need to get rid of almost everything dealing with our roles. In which case, we need to go to our User model. And we have all of these methods.

In which case, we need to go to our User model. And we have all of these methods. We have the roles here to get the roles, hasRole, hasAnyRole. Let's just delete all of those. And I think the only other place would be inside of the loadRoles middleware. Because here we check if the User is authenticated. We're adding the groups here, but that's not right. Why? I don't remember doing that. Anyway, we are going to delete all of that because we don't have roles anymore.

Plan Permissions Middleware Refactor5:57

I don't remember doing that. Anyway, we are going to delete all of that because we don't have roles anymore. Or at least we do, but we're not using them. But I don't want to delete this middleware just yet because we are going to load our permissions. Because now that we have groups, we can take this in a couple of different ways. Of course, yes, we could, inside of our code, check if a User is inside of a given group. And we didn't necessarily prepare for that. I mean, we could have with an auth code column or something like that.

And we didn't necessarily prepare for that. I mean, we could have with an auth code column or something like that. But there are a lot of other systems where the name is arbitrary. It's just that if you change the group name, you have to also update your code, which I guess that's okay. So yes, we can check if a User is inside of a given group. But ultimately, everything boils down to permissions. So in the next episode, we will refactor this LoadRolesMiddleware to load all of the permissions so that we will easily be able to determine what permissions a User has.

to load all of the permissions so that we will easily be able to determine what permissions a user has.

دوست دارید گاهی خبرهای Laracasts را ایمیل کنیم؟