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.
- 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 they 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.
Admin users in the feed are given ‘view’ permission on all students assigned to them through the data file.
For admin users that are no longer in the file, all their student permissions will be revoked.
For admin users in which their student assignments have changed, all their student permission will be updated to reflect the latest feed.
A ‘View’ permission gives the admin permission to :
- View student profile (username, name, department, entry year, profile photo etc.)
- View student plan (all courses they have taken and plan to take including placeholders, programs they are enrolled in and programs they are planning for)
- View student grades and GPA
- View exceptions made on a student
- View student audit progress
- View Notes made on a student that are made public by their owner
- View any other data that the college/university provides us about the student
This doesn’t 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.
Admins and students have access to ‘view’ all departments, which include department name and school.
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.
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 per se, 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 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.
Inheritance in Permissions
Stellic allows nested permissions. Permissions can be nested in three ways:
- Same Object Types: assigning a user permission to ‘audit-edit’ (ability to modify the audit) would automatically give the user audit-view (ability to view the audit).
- Different Object Types: a user may be given the permission ‘school-template-view’ (ability to view all templates in the school) which would give the user template-view (ability to view the template) on all the templates that would fall under that school.
- A student set defined in the qualifier file also behaves like an independent object. So assigning ‘student_set-student-view’ (ability to view all the students that fall under this student set) would give the user ‘view student-view’ (ability to view student information) on all the students under this student set
- Through Groups: if a group has a certain permission on an object, all users that are part of this group would also have that permission.
Creating Student Sets
Superadmins can create 'Student Sets' - or groups of students, in order to more quickly and efficiently assign permissions.
Once the a Student Set is created, any new students added to the platform will automatically be added to the group, without any manual maintenance needed.
Keep in mind that there can be only one Student Set for each type of criteria. For example, you cannot create both a Student Set that is Campus=Medford, and a set that is Campus=Medford AND Department=Computer Science. Those two sets would overlap. Instead, you could create two Student Sets that are Campus=Medford AND Department=Computer Science, and Campus=Medford AND Department=Computer Engineering. No students in those two sets would overlap, so that combination is allowed.