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.
|Each record in this table represents a team in the system.
|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.
|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).
|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_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)
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_sets_teams table allows the system to check for permissions on multiple teams. The following diagram illustrates table relationships in SugarBean's
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).
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',
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'.