Questions about TEAMS and ability to associate TEAMS (entire teams) as members of TEAMS

Our use-case is as such:  Our clients may be national companies with hundreds of offices and dozens of regions, and the hierarchy can change from client to client, so the functionality of allowing them 'TEAMS' is actually a good thing if it could be done to incorporate the flexibility and still keep it's usability.  However, we need to have clients which have regions which have branches.  In our previous app we associated client_users with branches and they had accessibility by branches that they were brach_users on and ability based on that user's role.  

I could see how this 'TEAMS' feature could be modified slightly to allow similar but even more flexible use from the client's side, but am having trouble conjuring up what would be the best practice of implementing something where the main team (Client, we can call it client_a_team) has sub-teams which are similar to, or include regions and regions can have teams that include branches.  

Let me know if this makes sense or if TEAM would only be for the singular client team and the other associations should be through some other type of object.  I have no problem either way, I just don't want to start down the wrong path when they other way would have been better from the onset.

I would find this useful as well

+ 1 for this. Seems like a job for the ancestry gem.

Dan Tappin Murray Bryant I may just hack around with this on a test app I have which I try out different scenarios and if I get something usable I will post back on this thread. 

As it stands in our current app (pre-jumpstart template) our clients do not use the dynamic flexibility of moving their users around and attaching with 'user_branches' because it is very tedious.  The ones who would use the functionality are our larger clients and usually just go with however we made the initial implementation for their users and branches.  However, being able to associate teams inside of teams would mean that our largest clients (the ones with tons of regions and branches) would actually start to use the feature to upkeep their massive teams, which would also give us a leg-up on our competition, since they have tedious implementations like, or worse than, our current rendition.

Visualize this: our large(as in client size) client_admin user for client_a sets up regions_team_a, regions_team_b, regions_team_c, and in those regions she puts 7-10 branches_teams that are associated with each region, and with each branch_team she associates 1-n numbers of users each who have their role (we only have 3 client roles: user, manager and admin).  At that point, moving teams associations would be as easy as drag-and-drop, rather than moving each individual user, how they would currently need to do it, which I personally wouldn't even do myself if I were tasked with it.  In addition the reporting features could be run at each team level for the users that are part of that team (this is where our clients love the report segregation for their regions and branches).  It's easy to aggregate and sub-aggregate data when the teams/(whatever you want to call them) are setup properly.

Chris Sonnier do you think you have an idea for this implementation?  I know that you know our use-case pretty well - I also think the teams would work for what you guys do as well, with some customization.

Little update - I got ancestry gem 3.0.7 (I believe) working just as I was leaving the office today. There are a few things needing to do different than the github instructions state when doing it with teams and using Postgres. At any rate, I am at a neighborhood party for the kids swim team posting this from my phone and will do an actual full update with instructions either later tonight or tomorrow morning. 

Dan Tappin  - absolute awesome call on the ancestry gem, the methods seem to work extremely well with the very light testing I did and the documentation is pretty robust. I think teams and ancestry properly implemented will be a game changer for our applications and especially reporting for our large multi-entity organization clients. This has the potential to let each of our clients set up their teams and users in the fashion that suits their company and hierarchy properly and manage it as well. 

Brandon B.  👍

Ok, so you will want to: 

# In your gemfile:
gem 'ancestry
# run
bundle install
# type command
rails g migration add_ancestry_to_teams ancestry:string:index
# change your migration file to this(this is pretty important, 
# if you don't change this you will likely need to rollback and start over):
class AddAncestryToTeams < ActiveRecord::Migration[6.0]
  disable_ddl_transaction!

  def change
    add_column :teams, :ancestry, :string
    add_index :teams, :ancestry, algorithm: :concurrently
  end
end
# run
rake db:migrate
# on your team model add:
has_ancestry

At this point you should have the ancestry functionality on the teams.

From the documentation at:  https://github.com/stefankroes/ancestry one can see that the nodes can be created from the parent down to the child or from the child referencing to the parent.  The other methods that the gem provides are actually quite useful like: has_children?, has_parent?, has_siblings?, is_childless?, reference back to parent_id, and many, many other methods that can be seen on the github page linked above.

I will do a modal for adding children from the parent and then do a reverse implementation for re-associating a child with a different parent from the child node as well.  I am sure I will get a lot more in-depth with it if it is actually doing what I hope it does, at which point I will make a nice JS(not my favorite language, haha) UI for drag and drop node associations and agile moving of teams within teams, if I get that done I will divulge the main portions of the code that can hopefully help some people trying to achieve the same thing.