Portal Identity Filter

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. Sometimes, depending on the query base used and the intent of the query, this filter may need to be adjusted or removed and replaced with a different custom SQL snippet. 

What is @identity?

Within the custom SQL "Portal Identity" filter, a variable of @identity is used. 

Portal Identity Filter

@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 in order to return the correct results.

How to edit the "Portal Identity" filter

When editing the "Portal Identity" filter, it is important to determine who or what the query results belong to. In the case of a Test Scores-based query in an Application security portal, the test scores belong to the person associated with the application.

Portal Identity Filter for Test Scores

(t.[record] = (select [person] from [application] where ([id] = @identity)))

  Tip

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!

@identity based on User Roles

If a User security portal needs to pull a list of athletes based on custom roles, a custom SQL snippet with a subquery is needed. In this scenario, we need to pull the list of roles for the user logged into the portal and then compare those roles with sport prompt values.

Portal Identity for User Roles

(spp.[value] in    (select dbo.getToken(' - ', r.[name], 2) as [name]
     from [role.user] ru
inner join [role] r on (r.[id] = ru.[role])
where (ru.[user] = @identity) and (r.[name] like 'Coach - %')
)
)
@identity based on User Population Permissions

If a User security portal needs to pull a list of records based on population permissions, a custom SQL snippet with an existence statement is needed. In this scenario, we need to check the population permissions for the user logged into the portal and then compare those populations with the populations the record is in. In this example, the query uses the Applications base and the filter is checking if the application populations match the user's population permissions.

Portal Identity for Application Population Permissions

exists(select * from [user.right] ur
inner join [population] pop on (pop.[population] = ur.[population])
where ([user] = @identity) and (pop.[record] = a__JID_.[id]))

If this was a person based query and we wanted to check for person populations, the custom SQL snippet would look like this. 

Portal Identity for Person Population Permissions

exists(select * from [user.right] ur
inner join [population] pop on (pop.[population] = ur.[population])
where ([user] = @identity) and (pop.[record] = p__JID_.[id]))
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?
4 out of 4 found this helpful