Portal Identity Filter
- 12 Sep 2024
- 4 minute read
- Print
- DarkLight
- PDF
Portal Identity Filter
- Updated 12 Sep 2024
- 4 minute read
- Print
- DarkLight
- PDF
Article summary
Did you find this summary helpful?
Thank you for your feedback
When creating a new query within a portal, a "Portal Identity" filter is automatically added. This filter is intended to limit the query results based on the record currently logged into the portal. This default filter is written in SQL, which is rarely user-friendly. On occasion, the default filter may need to be changed—typically, if the scope of the portal changes or doesn’t match your query.
This article explains what the @identity variable is and how it can be used with Configurable Joins queries to replace the default SQL filter in a portal.
Prerequisites
Configurable Joins: easy to moderate difficulty
What is @identity?
Within the default SQL "Portal Identity" filter, a variable of @identity is used.
@identity is a global portal variable that is the GUID of the record currently logged into the portal. If the portal uses Application security, @identity is the GUID of the applicant record. If the portal uses User security, @identity is the GUID of the user.
When the portal security and the query base are a match (ex: an application-based query in an Application security portal), the "Portal Identity" filter will typically not need to be changed, as the query is usually pulling information about the record logged into the portal. However, when the portal security and the query base do not match (ex: a test scores based query in an Application security portal), the "Portal Identity" filter will need to be changed to return the correct results.
How to edit or create the "Portal Identity" filter
When editing the Portal Identity filter, it is important to determine who or what the query results belong to. If your query uses the query base corresponding to the security type of your portal, creating the Portal Identity filter in Configurable Joins is very straightforward. If your query uses a different query base, you’ll need to use joins to reach the correct table corresponding to the portal security type.
Security Type and Query Base Match
To add a new Portal Identity filter when the security type and query base match, follow these steps:
Navigate to the query you wish to edit within your portal.
Click Filter to add a new filter.
Select the GUID filter corresponding to your query base/security type.
Enter
@identitywhen prompted, then Save.
.png?sv=2022-11-02&spr=https&st=2025-04-25T09%3A46%3A15Z&se=2025-04-25T09%3A56%3A15Z&sr=c&sp=r&sig=7MFggJFFrOFvPjHhcFKiO26gZAI3CoMwbayUn%2Fhr7T8%3D "image(491).png")
Security Type and Query Base Don’t Match
When your query base and portal security type don’t match, it’s necessary to add joins to reach the correct GUID filter for your security type. In the example of a Test Scores-based query in an Application security portal, the test scores belong to the person associated with the application. This is how the correct join path can be determined. As you create queries with Configurable Joins, you'll get a better sense of how the tables are connected, which will make adjusting this filter even easier! This example demonstrates the join path for Test Scores to Application:
Navigate to the Test Scores query you wish to edit within your portal. To create a new query on the Test Scores base, select:
Type: Configurable Joins
Category: Related
Base: Test
Within your query, add a new base join to Person. Save when prompted.
Add a subquery filter.
Within your subquery, add a join to Applications.
Add a new Filter. Select the GUID filter from the Applications heading. When prompted, enter
@identityas the GUID and Save.
@identity based on User Population Permissions
When administratively logged in to Slate, “by Population” queries limit results to only records within populations that the user has access to. However, these queries do not function within the portal tool. Instead, the query must manually filter for specific populations based on the @identity variable. This can be done using a subquery filter.
Note
The approach described here only works for populations that are assigned via role, not for populations assigned to individual permissions. This follows our best practice of using population-aware roles to assign populations to users.
We can build our subquery filter through the following join path: to the record’s populations, looking up that population, joining to all of the roles with that population, and then to all users with those roles. We then use the User GUID export to compare to the @identity variable to make sure the logged-in user has a role assigned to one of the record’s populations.
Navigate to the query you wish to edit within your portal.
Within your query, add a new subquery filter.
Change the Aggregate setting to Formula.
Add the following joins in this order:
From the base to Populations
From Populations to Lookup Population
From Lookup Population to Role User
From Role User to User
Add the GUID export from the User join.
Enter the following formula:
@User-GUID = @identity
When the "Portal Identity" filter is not needed
When opening a pop-up in a portal, a parameter is passed into the URL, typically the GUID of the record clicked. Since the information needed to populate the merge fields in the pop-up is related to the record clicked, rather than the user logged into the portal, the @identity variable is not needed. Instead, a custom SQL snippet referencing the parameter is used.
Where can I learn more about parameters?
If you need to have a custom SQL snippet that references parameters passed in from the portal, please refer to the Portal Pop-Ups and Filter-based Searching in Portals articles. In these cases, the @identity variable is typically not used.
Was this article helpful?
