Create Meaningful Membership Filters

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")

Related articles

Comments

0 comments

Please sign in to leave a comment.

Powered by Zendesk