Roles Guides Overview
The Roles feature allows portal Admin to direct content to specific groups of users and allows for more granular permissions.
The Roles Guides Overview provides information that is essential to utilizing Roles. It is advised to begin with The Roles Guides Overview before proceeding.
In this article:
Membership Filter Input
Users can modify and create membership filters through Admin Center and Admin Plus for Groups and Roles using DjangoQL.

Membership Filter Behavior
Users can expect that when a membership filter is saved, it will update users almost immediately (sometimes the update takes minutes).
If a new user is added to the Pathify database, they will not be uploaded to a group or role based on a membership filter until approximately the 45th minute of every hour.
Available Attributes
Not all user fields can be used in the membership filter. The membership filter has a drop-down feature to help with proper syntax and expected data types. Below is a table of user attributes and their allowed types that can be used to filter memberships:
When “id” is referenced in the data types column, that is referencing the “ID” column in Admin Plus. When “name” is referenced, this is the “NAME” column in Admin Plus. This must match EXACTLY, including casing, spaces, etc.
Attribute |
Data Type(s) |
Description |
Examples |
---|---|---|---|
id |
Integer |
This is the user’s primary ID in Pathify. This can be found in Admin Plus in Users > User. |
id = 5 id != 145 id > 1 and id < 45 |
alternate_id |
String |
This is the value being stored as “alternate id” in Pathify. This could be an alpha or numeric value but it should always be passed as a string when being used as a membership filter. |
alternate_id = “12345” alternate_id = “A75642” alternate_id = “W_770” |
sso_id |
String |
This is the value being stored as “sso id” in Pathify. This could be an alpha or numeric value but it should always be passed as a string when being used as a membership filter. |
sso_id = “E451475” |
name |
String |
This is the full user’s name value. This is not necessarily first name + last name from the import file if we are being provided preferred/nickname or full name values. This value must match the user’s name exactly. |
name = “Dave Smith” |
email |
String |
This is the user’s primary email value in Pathify and must match exactly. |
email = “user@university.edu” |
roles |
String |
This represents the role a user belongs to. If you’d like to include multiple roles, use the “roles in()” syntax. |
roles = “Student” roles in (“Student”, “Staff”, “Faculty”) |
department |
name - String id -integer |
This represents the department in Pathify. You can reference the department by the exact name or the Pathify id. |
department.id = 1 department.name in (“Example Department”, “Other Department”) |
school |
name - String id -integer |
This represents the school in Pathify. You can reference the school by the exact name or the Pathify id. |
school.id = 157 School.name = “School Name” |
campus |
name - String id -integer |
||
gender |
String |
||
course |
name - String id -integer |
||
international |
String |
||
is_active |
Boolean |
This represents if the user is active in Pathify or not using a True/False value. |
is_active = True is_active = False |
is_enriched (Not common) |
Boolean |
This represents if the user is enriched in Pathify or not using a True/False value. This is not a common feature used. If you’re not sure, please ask your Implementation lead. |
is_enriched = True is_enriched = False |
has_accepted_tc |
Boolean |
This represents if the user has accepted terms and conditions in Pathify or not using a True/False value. |
has_accepted_tc = True has_accepted_tc = False |
has_logged_in |
Boolean |
This represents if the user has logged in Pathify or not using a True/False value. |
has_logged_in = True has_logged_in = False |
subjects |
name - String id -integer Code - Year - Semester - |
Syntax Guidelines
Pathify uses raw DjangoQL for membership filters. DjangoQL’s syntax closely resembles Python’s, with only some minor differences.
- Use dot notation to reference model fields (e.g. “
campus.id
”, “department.name
”, etc). - Strings must be double-quoted. Single quotes are not supported. Escape a double quote with
\”
. - Boolean & null values:
True
,False
,None
. Users can only combine equality operators with Boolean values. - Logical operators “and” & “or” are available.
- Comparison operators work as expected:
=
,!=
,<
,<=
,>
,>=
- To test for whether a string contains a substring or not, use
~
,!~
, respectively. - The keywords “in” and “not in” are available to check if a value is present in a sequence (list, string, etc).
Valid Syntax |
Invalid Syntax |
---|---|
roles=”Admin” or roles=”Student” |
role=”” DEPRECATED |
roles in(“Student”, “Admin”, “Faculty”) |
roles=”Student, Admin, Faculty” |
is_active = True |
is_active > False |
Query Building Troubleshooting
- Make sure to query id’s as the correct data type (string, number, etc.)
- Use the roles in() syntax to pass in several role types
- Why does this syntax not work? roles = “Student” and roles = “Faculty”
- AND condition in multivalued attributes, in this case roles, act like OR. This is an inherent limitation of membership filters, related to the way ORM works.
- The current workaround is to use the following syntax: roles in(“Student”, “Faculty”)
- Ordering of queries matters. It’s important to order the queries from most to least restrictive. Example:
- Won't work: roles in ("Students") and roles not in ("Students In Residence")
- Will work: roles not in ("Students In Residence") and roles in ("Students")
Comments
0 comments
Please sign in to leave a comment.