A meeting space represents a virtual place or a persistent object (such as a meeting room) where conferences are held. A meeting space also helps users meet and find shared resources.
When you create a meeting space using the
spaces.create method, it returns
an instance of a spaces resource. The
resource includes the
SpaceConfig object that's
the configuration for the meeting space. It also contains the
ActiveConference object
that's a link to the current
conferenceRecords resource
within the meeting space.
The following sections detail how to configure a meeting space using several new beta objects and methods.
Set moderation and meeting access
Through the new beta objects, you can now set moderation modes, feature
restrictions, and the permissions users receive when they join a meeting. These
are set through the updated
SpaceConfig
object.
The moderation field is a pre-configured moderation mode for a meeting, with
the default controlled by the user's policies. It uses the
Moderation
object. When the moderation mode is on, the meeting owner has control over the
meeting with features such as co-host management (see
spaces.members)
and feature restrictions (see moderationRestrictions). For more information on
members, see Manage space members.
The moderationRestrictions field enforces moderation restrictions for the
meeting when moderation is on. It uses the
ModerationRestrictions
object. The restrictions define who has permission to
send chat messages and reactions, share their screen, and whether to restrict
the default role assigned to users as a viewer. The moderationRestrictions
field relies on a
RestrictionType
to apply the first three restrictions. The RestrictionType can be applied to
the meeting owner and co-host, or to all participants. The
DefaultJoinAsViewerType
applies the final permission where users join as contributors by default but
where hosts can also restrict users to join as viewers.
The firstJoinerType field sets whether users can join before the host for
conferences in this meeting space. It defines which users can join the meeting
first and if others are in a waiting state. It uses the
FirstJoinerType
object.
Manage space members
A meeting owner could always enter the meeting without knocking, but now you can
configure members who can also join the meeting without knocking. Additionally
members can be configured to have a role in the meeting, such as COHOST which
gives them the same abilities to manage the meeting as the meeting owner. For
more information about accessing a meeting space without knocking, see
AccessType.
The
spaces.members
resource includes the name, user, and role fields.
Note that a member is different from a
participant. A participant is a person joined
to a call or that uses Companion
mode
, watching as a viewer, or a room device connected to a call. There's one
conferenceRecords.participants
resource for each person.
You can manage space members using the following methods:
Each method takes a path parameter with the create and list methods using the
parent field to denote the meeting space, and the delete and get methods using
the name field to filter the results based on the meeting space and the member
name.
All methods, except delete, support the fields parameter in
SystemParameterContext
. When the fields parameter is omitted, the API response defaults to
"name,email,role,user".
The fields parameter relies on a
FieldMask
for response filtering. A FieldMask is a way for API callers to list fields a
request should return. It's a comma-delimited list of fields to specify only
certain fields in an object are used while leaving the other fields unchanged.
Using a FieldMask allows the API to avoid unnecessary work and improves
performance. A field mask is used for create, get, and list methods. For more
information on field masks, see Google Sheets API's Use field
masks.