Overview
Overview of the team framework.
Teams
Teams provides the ability to assign a record to multiple teams that will limit access at the record level. This provides more flexibility in sharing data across functional groups and is only applicable to paid versions of sugar.
Database Tables
| teams | Each record in this table represents a team in the system. |
| team_sets | Each record in this table represents a unique team combination. For example, each user’s private team will have a corresponding team set entry in this table. A team set may also be comprised of one or more teams. |
| team_sets_teams | The team_sets_teams table maintains the relationships to determine which teams belong to a team set. Each table that previously used the team_id column to maintain team security now uses the team_set_id column’s value to associate the record to team(s). |
| team_sets_modules | This table is used to manage team sets and keeps track of which modules have records that are or were associated to a particular team set. |
It is very important that you do not modify these tables without going through the PHP object methods. Manipuating the team sets with direct sql may cause undesired side effects in the system due to how the validations and security methods work.
Module Team Fields
In addition to the team tables, each module table also contains a team_id and team_set_id column. The team_set_id contains the id of a record in the team_sets table that conatins the unique combination of teams associated to the record. The team_id will contain the id of the promary team designated for a record.
Team Sets (team_set_id)
As mentioned above, Sugar implemented this feature not as a many-to-many relationship but as a one-to-many relationship. On each table that had a ‘team_id’ field we added a ‘team_set_id’ field. We have also added a ‘team_sets’ table which maintains the team_set_id, a ‘team_sets_teams’ table which relates a team set to the teams. When performing a team based query we use the ‘team_set_id’ field on the module table to join to ‘team_sets_teams.team_set_id’ and then join all of the teams associated with that set. Given the list of teams from team_memberships we can then decide if the user has access to the record.
Primary Team (team_id)
The ‘team_id’ is still being used, not only to support backwards compatibility with workflow and reports but also to provide some additional features. When displaying a list we use the team set to determine whether the user has access to the record, but when displaying the data, we show the team from team id in the list. When the user performs a mouse over on that team Sugar performs an Ajax call to display all of the teams associated with the record. This ‘team_id’ field is designated as the Primary Team because it is the first team shown in the list, and for sales territory management purposes, can designate the team that actually owns the record and can report on it.
Team Security
The team_sets_teams table allows the system to check for permissions on multiple teams. The following diagram illustrates table relationships in SugarBean’s add_team_security_where_clause method.
Using the team_sets_teams table the system will determine which teams are associated with the team_set_id and then look in the team_memberships table for users that belong to the team(s).
TeamSetLink
Typically any relationship in a class is handled by the data/Link2.php class. As a part of Dynamic Teams, we introduced the ability to provide your own custom Link class to handle some of the functionality related to managing relationships. The team_security parent vardefs in the sugar objects contains the following in the ‘teams’ field definition:
'link_class' => 'TeamSetLink','link_file' => 'modules/Teams/TeamSetLink.php',
The link_class entry defines the class name we are using and the link_file tells us where that class file is located. This class extends the legacy Link.php and overrides some of the methods used to handle relationships such as ‘add’ and ‘delete’.
