Permissions are the settings within Stellic that control what users can see and do. Stellic allows a variety of permissions: from whether users can create new audits to whether a user can perform a specific action on a student.
If you aren’t able to view certain users or buttons, this is most likely because you do not have the permissions settings that allow those actions. Contact your administrator for a permissions update, or for help with those actions.
We’ll automatically allow view and edit permissions on an advisors’ specific advisees. Students also have the ability to add advisors to their plan (Settings Sharing Plan), so that users other than their primary advisor can view their plan and/or audit. They can choose whether the additional advisor has access to just their plan (no grades shown) or plan and audit (with grades).
How Stellic Permissions Function
There are two ways for permissions to be assigned within Stellic:
1) Permissions can be manually assigned through the Permissions tab in the platform. This tab is available for superadmins only.
2) Permissions can be setup and automatically assigned through feeder files.
As a rule, Stellic should always have a single source of truth for a given permission type (either assigned manually, or through feeder files). As an example, let's look at the permission for an advisor to chat with a student. This specific permission could be:
Managed from the Stellic app. In this case, a user can assign someone this permission on a particular student and it will persist forever until this permission is removed explicitly from the app.
Managed from the feeder files. In this case, every time we update the data (in most cases, once a day) we will
assign this permission to anyone who shows up in the feeder data as an advisor for a student
remove this permission from anyone who had this permission initially but no longer does. We will remove permissions if:
the user shows up in the data but does not have this permission on Student X anymore or
the user is entirely missing from the feeder data.
(Permissions will not be removed from superadmins, even if the feeder file dictates otherwise)
Put another way -- Stellic will pick the most recent data to set a permission. If we get data files on a 24hr basis, then permissions will be reset to match the data file each time that is run. This means that if a Super Admin makes a manual change that conflicts with the data file, it would be reset when the next file is run. For permanent changes to permissions, the file needs to reflect these changes.
Generally, most universities opt to manage "student-view" and "student-chat" through the feeder mechanism. With the behavior explained above, what this means is that if you were to assign "student-view" to anyone that doesn't show up in the feeder data, that permission only persists up until the next data update.
Note that however, if you assign someone "student-make_exception" (assuming only "student-view" and "student-chat" are managed through the feeder), this permission will persist until you remove it because this is not a permission managed through the feeder mechanism.
It's a good idea to decide which types of permissions will be managed manually and which through feeder files, and keep that consistent to eliminate any confusion.
Default Permissions
Student
By default, admins and advisors can see no student data in Stellic. Permissions to view students can be assigned via the feed or via the application as referenced above.
For additional information on what student-view permissions look like, please refer to our article dedicated to student view options. View permissions do not allow the admin to make any actions on the student (such as make exceptions). Additional permissions can be set by a Super Admin.
Students can not view any other student information. Students can only access their own information in Stellic.
Department
Admins and students have access to ‘view’ all departments, which include department name and school.
Program
Admins have access to ‘view’ all programs, which include program name, description, department and school.
Students can view all programs that have an audit that applies to them (meaning the entry year/catalog term criteria matches the student).
Admins have access to ‘view’ all published audits for all programs. Audits include a list of program requirements, who published the audit and when.
Students cannot view an audit in the same way that an admin user can - instead they can see how the audit applies to their current plan, which also includes a description of the requirements. For a program that does not have an audit that can be applied to their plan, the student will not see any audit. An audit can be applied to a student if it has a criteria that matches the student (e.g. audit applies to students with entry year 2013 and above). In short, a student can only see the audit requirements if they match the audit criteria.
Pathways
Pathways are created by Admins and represent the recommended course sequence for a specific program.
Admins and Students have access to ‘view’ all Pathways, which includes all the courses and how the audit of the program matches the Pathway.