Team join/invites | Review my approach

Hey @automica !

Thank you for your feedback and kinda confirming that my steps/approach makes sense.

you might want to add a step to invalidate the token to prevent one person approving and then another person disapproving.

Correct, as soon as a member approves/disapproves the token must be deleted to avoid users messing around with it.

I assume your approval link will take the user to login and then see the user they are approving before they approve them?

Euh no, userA (=wants to join) is already registered and logged in. He can edit his account, chat with friends and create a team (or join a team if already created). In the case he needs to join, he'll click 'join-button'.

This click on button, will create a unique token (stored in database table for this) and a notification should be sent to UserB(already member). I'm planning to create a small user-profile-card that can be part of this notification/message, so UserB can immediately see who it is and decide to accept or refuse.

you might also want to add a 'team_leader' role 

That is actually a very good idea, only problem with trying to implement this is the following situation.

Imagine you and me are in a team. You are actually the one who 'founded' the team (or the one that invests time/money/etc) and I'm just a member.

If I'm first to register the team, I would be team_leader. While in reality you would/should be TL.... Hmmm maybe flaw in my approach... Good point though...

It sounds like you've considered the use cases.

Maybe you could add a 'team_founder' role. the main thing is who gets permission to dispand the team, it might be that a team is dispanded when everyone leaves.

There may be some auditing reasons why you might want to keep a team especially if they are generating content.

BTW this is a prime opportunity to approach this with Test Driven Development, if you aren't already. if you can describe the various ways to join or approve other members in to your team, you can write some tests to cover this and then you'll have a reliable way of ensuring all your permissions work when you do further development.

Depending on complexity, you might also want consider the multitenancy setup covered by this series:

https://laracasts.com/series/multitenancy-in-practice

this allows you separation between teams content. i'd recommend to watch it before you start any actual coding on this as you'll find some good techniques.

@automica

Depending on complexity

Mate, it's already complex enough as it is 😂

BTW this is a prime opportunity to approach this with Test Driven Development

I had to look up what 'Test driven Development' meant? I saw a few courses (fex Build a Laravel App with TDD) but I thought that was some sort of package or something 😇

Maybe you could add a 'team_founder' role. the main thing is who gets permission to dispand the team, it might be that a team is dispanded when everyone leaves.

Yeah, think you are right... Ok, I'll have to think a bit more about it and decide what/how, until I have a solid plan/approach.

At same time I'll mark your last answer as best, it basically says all that needs to be said.

Thanks you btw!

no worries. always happy to help.

Hi @automica !

Thank you for recommending the series on multitenancy. This might sound a bit uninformed, but in a way am I not already (sort of) applying this?

As in each tenant => team And in my controllers I set conditionals like :

            //Check if user is already part of a team
        if(isset(Auth::user()->team_id)){

and

            //Find team associated with user
        $team = Team::where('id', Auth::User()->team_id)->firstOrFail();

If I understand correctly, by applying multitenancy you base all data around the tenant (id). Therefore users that are part of the tenant(id) can only see data belonging to that tenant.

So by applying conditionals as above I'm doing something similar, with the only exception that I'll need to be able to share data between Teams. F.ex.

User A of Team A can go to /results
User A of Team A can consult results of Team B

or

User A of Team A (f.ex. tenant id 1) can go to /discuss

User A can comment / talk  with User B of Team B (f.ex. tenant id 2) 

-> basically other Users of other Teams (= other tenants)

As I'm using conditionals and specify that when data displayed can only be related to the team the user is part of. I conclude It's better to put these calls in a global scope. (resulting in cleaner code and less chances of me forgetting, making mistake, etc.)

Or did I fail in understanding the purpose / goal of multitenancy?

@< gdb > if you want to keep your teams distinct then the multitenancy approach is a good one.

As you say the teams have visibility of each then you wont want to be as restrictive as multitenancy.

If you can use global scopes that's often better, but TBH if you can manage the way you are currently coding, and that makes it simpler to implement, then keep on with the way you are doing it.