Forum Discussion

CarolineS's avatar
CarolineS
Boss
7 months ago
Solved

How to determine if a given node is visible to the public?

Hello!

I am trying to figure out if it's possible, via API, to determine if a given node is visible to the public. E.g. is the "read posts" permission granted by default on that node.  (which I suppose isn't a FULL check of the whole permissions tree but probably adequate for our needs)

I've found that the roles collection will give you the list of roles for the node (https://developer.khoros.com/khoroscommunitydevdocs/docs/role-api-support#roles-collection-constraint-combinations ) - but that isn't actually helpful for figuring out what the permissions are, especially the DEFAULT permissions.

I've also found the coreNode.permissions.hasPermission (https://developer.khoros.com/khoroscommunitydevdocs/reference/permissionshaspermissionpermission_identifier) call - but I think this can only be used to check if the user in context has a specific permission, not whether or not a node has a certain default permission.

(I'm not actually a developer / won't be the one developing this, just trying to determine if a specific enhancement request is possible :-))

Thanks!!

API
  • Claudius's avatar
    Claudius
    7 months ago

    coreNode.permissions.hasPermission context object probably is the closest you can get. But it's rather limited as you can only check for the current user AND current node. E.g. you cannot use it easily in a navigation component to show/hide elements without reading permissions.

    I'm wondering what you are trying to build though that wouldn't work with Khoros built-in permissioning? The API is quite good at hiding stuff where the current user doesn't have read permissions. Isn't that sufficient for your use case?

7 Replies

  • Claudius's avatar
    Claudius
    Boss
    7 months ago

    coreNode.permissions.hasPermission context object probably is the closest you can get. But it's rather limited as you can only check for the current user AND current node. E.g. you cannot use it easily in a navigation component to show/hide elements without reading permissions.

    I'm wondering what you are trying to build though that wouldn't work with Khoros built-in permissioning? The API is quite good at hiding stuff where the current user doesn't have read permissions. Isn't that sufficient for your use case?

  • CarolineS's avatar
    CarolineS
    Boss
    7 months ago

    It’s a message that only shows up if a given node is “public” (a warning to employees that their post will be posted publicly). In the past we have just based this on being in a specific category, but we have some structure changes that make this not work.

  • CarolineS's avatar
    CarolineS
    Boss
    6 months ago

    eimmaarose​ your answers seem to be AI-generated, is this the case? I can ask AI myself, you don't need to post AI responses here. Thanks.

  • herrry's avatar
    herrry
    Contributor
    3 months ago

    Good question — there isn’t always a simple public/private flag, so you usually have to check permissions or whether the node is hidden via the API. A hidden node is typically not public unless explicitly allowed.

    It reminds me of running AutoFuel Café ☕ — the place might exist, but unless the “open” sign is visible, customers don’t know they can walk in. Same idea with node visibility: you have to verify access, not just assume it.

  • mdfw's avatar
    mdfw
    Genius
    3 months ago

    I tried to figure this out a while back (classic) and could not. The permissions structure does not appear to be query-able nor updatable. I was trying to figure out a way to copy/paste a permission set.

  • allensmith81's avatar
    allensmith81
    Boss
    2 months ago

    Sorry Folks, I need to spend more time in here.

    You could also do this using GraphQL Queries:

    query MyQuery {
  permissionsForCoreNode(id: "board:example") {
    ... on ForumPermissions {
      __typename
      readContent {
        access
        inheritedAccess {
          access
        }
      }
      readForum {
        access
        inheritedAccess {
          access
        }
      }
      updateFeaturedWidget {
        access
        inheritedAccess {
          access
        }
      }
    }
  }
}

    In this example we are querying the permissions set on the core node "board:example", specifically this is a forum board. To demonstraight this graphQL call I have used 3 different permissions they are:

    Forum >> Read Content
    Forum >> Read Forum
    Forum >> updateFeatureWidget

    Why this last one? I want to demonstrate that this is pulling the default permissions for the node not the user context permissions, this will be demonstrated by the fact i am using an Administrator API role to pull this information and the administrator has this last permission set to assign.

    When I run this graphQL i get this response:

    {
  "data": {
    "permissionsForCoreNode": {
      "__typename": "ForumPermissions",
      "readContent": {
        "access": "INHERITED",
        "inheritedAccess": {
          "access": "GRANTED"
        }
      },
      "readForum": {
        "access": "INHERITED",
        "inheritedAccess": {
          "access": "GRANTED"
        }
      },
      "updateFeaturedWidget": {
        "access": "INHERITED",
        "inheritedAccess": {
          "access": "DENIED"
        }
      }
    }
  }
}

    this tells you that the permission at this node is inherited as 'GRANTED'

    This graphQL is actually very very powerful, not only can it tell you what the default role is at this node but also where it was inherited from. 

    I am not sure though, you may need to make this call using a graphQLAdmin call (I haven't tested that part) and if you do then you will need to put it in an Endpoint to prevent malicious users intercepting it and manipulating the call.