Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Helen’s notes about queries from digging through the forums and KB webinars/articles 4/20/2023:

Queries:

  • There are multiple layers of "locks" on queries:

    • Is the query configured to be shared or not?

    • What is the Read permission for the query base?

    • Each query can have individual permission settings that can grant access by a specific user, role, etc.

  • Summary:

    • To be able to see the name of the query listed in the Query module (and the folder that contains it), the user must either "own" the query or the query must be configured as "shared." Basically, if a query is configured as "shared" it is going to show up and be visible to all users with the minimum "query" permission, but being able to edit/run the query depends on other settings.

    • Giving users Query + Query (Edit All Users) allows the user the ability to edit/run a query that is configured as shared unless there are other permission restrictions preventing it, such as:

      • It is in a realm that the user does not have access to

      • It is built on a query base that the user doesn’t have universal/functional permission to (i.e. Person Lookup not restricted by population) (from old slate template library/query tools)

    • It is possible to "get around" giving a user Query (Edit All Users) permission by using the permission settings within the query to allow them access, which can be controlled by user/role/custom permission and also can be set to either view/run and/or edit the query.

  • Assigning the user the permission of "Query" will allow them to get into the Query module/environment and they will be able to see their personal queries / see any other query that is configured to be "shared."

    • If a query is not configured to be shared it will not show up at all (including the folder) except for the user who "owns" the query (in their "Personal" query view.

    • Creating or running existing queries depends on other permission settings, so having just this permission functionally just lets them view the query area but not really do anything else.

    • Must have this permission if any other query permissions are added (i.e., need Query AND Query (edit all users), not just the latter)

    • Query bases are also locked down/controlled by permissions:

      • For the "local" (old) query bases, this is configured in the Dashboard > Query Base as the "Read Permission". Application was set to "Application Lookup" and Prospects was set to "Person Lookup." Because these permissions are population-aware, if they are assigned via a role/individually through the populations tab, then the user will not be able to access queries with that base, because they do not have the full Application/Person Lookup permission.

        • This seems to be indicated by the little lock symbol being next to the name of the query.

      • For configurable joins queries…

      • If the person has no non-population aware permissions that give them access to either the old query bases or configurable joins, they will not be able to create a query at all. They can see that "shared" queries exist, but they cannot open or run them.

    • One strategy with old query bases/not having non-population aware App or Person Lookup access is to grant access to individual queries directly via the permissions within the query itself--if given access there, the user can run the query regardless of if they have permissions to the query base itself.

      • If you give the ability to edit in addition to view/run, then the user could add filters that would end up pulling records not in the population you want them to have access to in that query, so they could view them but still wouldn't be able to get into the record.

  • Queries can be put into Realms to allow compartmentalization of who can build, run, and edit without affecting queries in other Realms. What a user can do is still controlled by a User Permission, but Realms allow their impact to be limited to only appropriate objects.

    • How "sharing" a query affects the behavior of the realm:

      • The Realm provides the highest level of restriction. Checked or not, only users in that realm can access the query.

      • If the sharing setting is checked, then users in the Realm with any relevant query permissions may access that query.

      • If the sharing setting is not checked, then only users in the Realm with the "query (edit all users)" permissions may access the query. The sharing setting grants users with a certain level of access to the query if they are also in that realm.

        • If a user does not have the realm assigned to their user account but does have query (edit all users) they will still see the query but if they try and open it, they will get a "Forbidden" message.

        • Even if the user has access to the realm and the query is shared, if the user doesn't have access to the query base (via the assigned Read Permission) then they won't be able to run it.

  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.