Objects in 25Live have two levels of security which determine how users can interact with them:
- Object security, also known as "editing permissions", determines who is allowed to see an object's details and make changes
- Assignment policy, which determines who makes requests and who approves them (available only for locations and resources)
Object security sets the basic level of interaction a user is allowed to have with an event, location, organization, report, or resource in 25Live.
There are four levels of permissions for a given object which grant the following actions:
If you set object security to...
Members of the security group...
|Can't view the event(s)
|Can view the event(s)
|Can view and edit the event(s)
|Edit, Delete, Copy
|Can view, edit, delete, and copy the event(s)
For the vast majority of users, View Only rights are the most appropriate setting. This includes reports, as users do not need permission to edit a report in order to run it.
Use lower permissions (Not Visible) when you want to hide objects from a user, and use higher ones (Edit or better) when you want a user to have administrative powers over an object, including changing its name and other vital statistics.
- Configuring Object Security (for all objects except events)
- Configuring Object Security for Events, Folders, and Cabinets
Assignment policy dictates how a user interacts with a location or resource during the scheduling process. It determines whether a user is able to request or assign an object, whether they can unassign it from existing events, and whether they can approve requests from others.
Note: Organizations, Events, and Reports Don't Have Assignment policy
Please note that assignment policy affects locations and resources only. Anyone who has permission to view an organization is able to attach it to events without requiring approval. If you wish to set up an alert that an organization has been using, consider using notification policy.
There are five standard levels of assignment policy with the following permissions:
- Assign, Unassign, Approve
- Assign, Unassign
- Request, Unassign
- Not Requestable
If desired, groups can have custom assignment policy rights instead of standard rights. This allows you to set custom combinations for assignment rights and unassignment rights. For example, users can have "Assign and Approve" assignment rights and "No Unassign" unassignment rights. For more information about custom assignment policy, see: Configuring Assignment Policy.
If you set Assignment Right to...
Members of the security group...
|Can directly assign a location or resource to an event. As soon as the assignment is complete, the location is unavailable for others to assign.
|Can choose to add a location or resource, but it is not fully assigned until it is approved. Others may still assign or request it for events at the same time.
|Can remove a location or resource from an event, making it available again. Users without this ability trigger a request for unassignment which is not carried out until approved.
|Can approve requests for assignment or unassignment permissions as workflow tasks. Once approved, the (un)assignment is carried out as normal.
Cannot request a location or resource that is Not Requestable. It will still be visible in searches and calendars, but cannot be requested for events.
Note: The Assignment Window can still be set even when this option is in place.
A security group's default assignment policy on locations can be temporarily overridden by assignment windows when creating or editing events that take place in the near future.