Object Permissions Guide Overview
In the Pathify portal, object permissions are used to control what content users/roles will be able to view in the portal. In this article, view the wide variety of options for how to set object permissions in the portal.
In this article:
- Object Permissions for Viewing Event Calendars and Widgets
- Setting Object Permissions for Calendars
- Setting Object Permissions for Widgets
- Object Permissions for Viewing Pages
- Object Permissions for Viewing Tools
- Object Permissions for Viewing Groups
- Object Permissions for Non Portal Admins
- Object Permissions Page Category Example
- Limited Object Permissions for Non-Portal Admins when Generating Announcements and Tasks
- Role Permissions for Sending Announcements Example
Object Permissions for Viewing Event Calendars and Widgets
When institutions set up Calendars in order to view events coming in from iCal Feeds or they configure their widgets, they may decide which roles and/or specific users in the portal will need to see those calendars and widgets.
Setting Object Permissions for Calendars
For widgets, institutions may set up object permissions to allow for viewing at the widget level in the Admin Center by assigning a role or user permissions to view the calendar . If a user is not in the role specified, they will not be able to see the widget in the Dashboard.
For Calendars, institutions may set up object permissions to allow for viewing a calendar feed in the Admin Center by assigning a role or user permissions to view the calendar. If a user is not in the role specified, they will not be able to see the calendar feed on either the Dashboard, in their events calendar or in the Global Events screen.
Setting Object Permissions for Widgets
For widgets, institutions may set up object permissions to allow for viewing at the widget level in the Admin Center by assigning a role or user permissions to view the widget. If a user is not in the role specified, they will not be able to see the widget in the Dashboard.
Object Permissions for Viewing Pages
When setting up pages, you may decide that certain cohorts of users in the portal (identified by their assigned roles) will need to see individual pages, page categories, or both.
Example #1: Role is given permissions to view all Pages within a category
By giving users with the Applicant role the ability to view all pages in the Future Students category, this ensures that Applicants can go to that category and view any pages that have been assigned to that category. Users that are not assigned to that role will not be able to see that category nor any of the associated pages.
Example #2: Role is given permission to view an individual page.
The exception to this is if the Object Permission is assigned at the individual page level. You may set up your portal so that users or roles can only see specific pages within the category, not the whole list of pages.
For example, by making the Admissions Application page in the Future Students category visible to the Applicant role, this ensures that Applicants can go to that category and view just that page. Because they have been assigned Object Permission at the Page level, they will automatically be able to see that category even if no Object Permissions were assigned at the category level. Any user that is not assigned to that role would not be able to see that specific page.
Object Permissions for Viewing Tools
When setting up tools, you will decide which users will need to see the tools intended for their role. This can be done at the Tool level only. Any role assigned to see a Tool will automatically see the category the tool is associated with by default. If the user does not have the ability to see any tools within a tool category, the user will also not be able to see the category.
Object Permissions for Viewing Groups
While setting up your groups you have the option to decide what groups will be visible to a specific role. Please note: A group’s visibility is also dependent on whether the group is set to public/private and the group category where the group resides.
Group Permissions Examples:
Private Group Membership
If a group is created as a private group, only people that are members of the group via a membership filter or have been added to the group will be able to search for and view a private group.
Public Group Membership
If a group is created as a public group, members and prospective members will be able to search for and join the group. Non-members won’t be able to view the group unless object permissions have been assigned to the Group or Group Category to allow users/roles to find and join the group.
Please Note: The exception to viewing a public group is if the Object Permission has been established at the category level for which the group has been assigned.
Public Group Category Permissions
For Groups, you may set up object permissions for viewing at the Category level in the Admin Center by assigning a role or user permissions to view the group category. If a user is not in the role that has been assigned to view the Group Category, they will not be able to see the group in the portal even if the group tied to the category is public.
Private Group Category Permissions
If a private group is associated with a group category that has been assigned object permissions for viewing, users not associated with the private group will still not be able to see the group because it remains private. The only way users can view a private group is by being added manually or through a membership filter.
Object Permissions for Non Portal Admins
Institutions may choose to assign permissions to create/edit content (Groups, Pages, Tools) to a role or even individual users that are not portal admins.
When content permissions are given to a user or role that has general access to create that content which means they can create and/or edit groups, pages and tools anywhere within the portal.
By assigning roles and/or individual users the ability to Add, or Change pages at the category level, this allows them to create/edit content only within that selected category.
Object Permissions Page Category Example
Permissions: Ability to Add and Edit Pages in a Page Category
By giving Jillie the ability to add pages under the Future Students category, this ensures that Jillie can go in and create new pages tied to that category. Any pages that she creates in this category, can also be edited by Jillie. Jillie can not create and/or edit any other pages in any other category unless specified. She also can not edit any existing pages in this category that were created by somebody else.
Permissions: Ability to Change and Edit Pages in a Category
Some institutions may wish to give a user or role both the ability to change and add pages in a category. To do this, simply add the user/role to be able to change and add pages in a category.

Limited Object Permissions for Non-Portal Admins when Generating Announcements and Tasks:
Institutions may also choose to allow non-portal admins (users and/or roles) to have the ability to assign a task to another user or send portal announcements.
When object permissions are configured at the role level within the Admin Center, that person or role has access to select specific roles available to them even though many more roles may exist within the portal. The user would not be able to send an announcement or generate a task for anybody that is not included in the configuration.
Role Permissions for Sending Announcements Example
By going into the student role and giving Jillie the ability to send announcements to that role, this ensures that Jillie can go in and send new Notice announcements to just users in the student role. Jillie can only send Notice announcements to the users/roles indicated. Note: If Jillie needs to be able to also send Alerts or Emergencies in addition to Notices to limited users/roles, Portal Admins will also need to assign her the Send alert and Send emergency permissions.
Comments
0 comments
Please sign in to leave a comment.