Teams
Overview
Teams provide the ability to limit access at the record level, allowing sharing flexibility across functional groups. Developers can manipulate teams programmatically provided they understand Sugar's visibility framework.
For more information on teams, please refer to the Team Management documentation.
Database Tables
| Table | Description |
| 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 keep track of which modules have records that are or were associated to a particular team set. |
Never 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 contains the unique combination of teams associated with the record. The team_id will contain the id of the primary 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, and 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. When displaying the data, we show the team from team id in the list. When the user performs a mouseover 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 contain 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'.