How to determine if a user has access to any Verint content type?

Hi Dmitry,

You can check permissions before calling IContents.Get. 

(+) Show Permission (v3) REST Endpoint - API Documentation - Verint Community 11.x - Verint | Telligent Community

Hi Brian, thanks for the answer, yes, I considered this option as the most backup plan. Because in the current API, I cannot find the "universal" permission ID.

Previously, when using the search API core_v2_searchResult.Get, I could determine if I had read access to any type of content without looking up the permission ID itself.

This approach ensured that permission check would always work, even under the following scenarios:

* different major versions of the instance (in version 12 a new type of content was added: "articles")

* custom content types can be installed on the client instance

Right now I see the following way to check permissions:

var permissionId = null;
if (contentTypeId == Types.Group) {
    permissionId = core_v2_groupPermissions.ReadGroup;
} else if (contentTypeId == Types.BlogApp) {
    permissionId = core_v2_blogPermissions.ReadBlog;
} else if (contentTypeId == Types.MyCustomType1) {
    permissionId = dm_v2_myCustomType1.Read;
}  else if (contentTypeId == Types.MyCustomType2) {
    permissionId = dm_v2_myCustomType2.Read;
} else if () {
    // all OOTB content types...
} else if () {
    // all custom content types... 
}

var hasReadPermission = core_v2_permission.Get(permissionId, userId, contentId, contentTypeId);

Is there a more versatile way to avoid the problem described above?

Brian Dooley , any thoughts on Dmitry Mandrichenko 's follow-up question?

This call to the Content API's Get() method should not throw a ThreadAbort exception or redirect. Could you provide more detail about the type of content that was being reviewed?

The short answer is that this should not be required to implement the original behavior.

Internally, there is an approach for checking permission by their "action" such as "read", however, this is used extremely rarely even internally, because of other checks.

The source of the problem in this use case is that failure of the access denied error being returned on the API entity's error collection as expected. That should be fixed in newer releases, however, I'd like to verify with a more concrete scenario so I can verify that the exact issue that was encountered is resolved and I can provide a resolution version number.

To follow-up, this was resolved in version 12.0+ as part of the bug:

Ben, more detailed steps to reproduce this issue (ThreadAbort exception):

1. Create a sub-group with Private (Unlisted) privacy
2. Get the Content ID and Content Type ID for this group
3. Place new widget on the main page in the header and "lock" it with the following code:

#set($cid = $core_v2_utility.ParseGuid('d1469c05-58bf-4651-9c6f-72457eb2a3e5'))
#set($ctid = $core_v2_utility.ParseGuid('23b05a61-c3e5-4451-90d9-bfa00453bce4'))

$core_v2_content.Get($cid, $ctid)

where,

$cid - Content ID of the private sub-group

$ctid - Content Type ID of the private sub-group

4. Go to the page from an unlogged/anonymous user https://{community}/login

Exceptions:

Browser output:

Verint version: 11.1.9.17830 (Developer mode)

Thank you. That further verifies that this is the issue fixed by this existing bug (in version 12+). I've logged another bug to consider backporting this correction to 11.1:

Ben Tiedt , thank you very much for looking into this issue!