AFCS开发者指南3.1.4 UserRoles（用户角色）
One of the AFCS’s basic tenets is that every messaging call made by any client requires permissions
validation. A user role is a numerical expression of a user’s permission’s “level” for a given room element.
Elements of a room include all of the elements in our three level hierarchy:
The room itself (sometimes referred to the “root” user role)
A collection node
A node within a collection node
Messaging and Permissions
Cocomo Developer Guide MessageItems 27
User roles for a user cascade down from the room level to its collection nodes and on down to its
individual nodes. For example, a user may be a viewer for the room at large but is designated as the note
taker for a specific note pod. In this case, the note pod’s collection node can be set to have role value for
that user which is higher than the user’s overall role within the room (such as UserRoles.PUBLISHER).
Other users for the pod’s collection nodes and nodes would just inherit their role from the room.
A node’s NodeConfiguration has two specific settings which intersect with user roles: accessModel
and publishModel. Respectively, these values express the minimum user role required to subscribe and
publish to that node. This allows hosts to lower or raise the role requirements for node users to perform
publish and subscribe actions. Most of the shared Model and collaborative classes have API’s for changing
both the publishModel and accessModel.
The default user roles are enumerated on the class com.adobe.rtc.messaging.UserRoles and
consist of the following:
UserRoles.VIEWER: This is the default NodeConfiguration value for accessModel which allows
subscribing to but not publishing messages.
UserRoles.PUBLISHER: This is the default NodeConfiguration value for publishModel which
allows publishing and subscribing, but does not allow configuration.
UserRoles.OWNER: This is the role typically provided to the host or moderator. Users with this role can
publish, subscribe, add and remove both collection nodes and nodes, configure nodes, and set user
roles.
UserRoles.OWNER is the highest role possible, is able to both publish and subscribe to any node, as well
as being the only users who may create and delete nodes and collection nodes, and modify user roles and
NodeConfigurations. The owner is usually the who can add new collection nodes or new functionality
to a room.
While NodeConfiguration settings for permissions often stay static, user roles are by nature dynamic -
they are first assigned as a user is validated and enters the room. Subsequent changes to user roles on
collection nodes and nodes typically occur as a host user grants higher (or lower) role values to users as
the result of the situation at hand.
Tip: The SDK’s CustomRoster example demonstrates how to manipulate user roles.
