IBM CMOD Query Restrictions - Revision history

Jderrick: Fixed link to arsdoc update

2019-11-13T14:23:36Z

Fixed link to arsdoc update

← Older revision		Revision as of 14:23, 13 November 2019
Line 16:		Line 16:
	BRANCH_NO IN (1234, 1235, 1236, 1237, 1238, 1239)		BRANCH_NO IN (1234, 1235, 1236, 1237, 1238, 1239)

	Further, if you have a type of report for which there are amendments or revisions (for example, governmental tax forms provided to customers of the bank) you may want to obscure the prior versions of the documents by marking them as inactive with the [[arsdoc\|arsdoc update]] command, to change the contents of a field from 'VISIBLE' to 'HIDDEN', and creating a group with the following query restriction:		Further, if you have a type of report for which there are amendments or revisions (for example, governmental tax forms provided to customers of the bank) you may want to obscure the prior versions of the documents by marking them as inactive with the [[arsdoc update\|arsdoc update]] command, to change the contents of a field from 'VISIBLE' to 'HIDDEN', and creating a group with the following query restriction:

	RPT_VISIBILITY = 'VISIBLE'		RPT_VISIBILITY = 'VISIBLE'

Jderrick: /* Examples */

2019-11-13T14:22:53Z

Examples

← Older revision		Revision as of 14:22, 13 November 2019
Line 15:		Line 15:

	BRANCH_NO IN (1234, 1235, 1236, 1237, 1238, 1239)		BRANCH_NO IN (1234, 1235, 1236, 1237, 1238, 1239)

			Further, if you have a type of report for which there are amendments or revisions (for example, governmental tax forms provided to customers of the bank) you may want to obscure the prior versions of the documents by marking them as inactive with the [[arsdoc\|arsdoc update]] command, to change the contents of a field from 'VISIBLE' to 'HIDDEN', and creating a group with the following query restriction:

			RPT_VISIBILITY = 'VISIBLE'

	This provides the regional manager access to reports from 6 different branches, without needing to define a 'region' field in the Application Group.		This provides the regional manager access to reports from 6 different branches, without needing to define a 'region' field in the Application Group.

Jderrick: Content Manager OnDemand Query Restrictions

2019-11-13T14:11:13Z

Content Manager OnDemand Query Restrictions

← Older revision		Revision as of 14:11, 13 November 2019
Line 2:		Line 2:

	== How Query Restrictions Work ==		== How Query Restrictions Work ==
	Query restrictions are created inside Group definitions. They take the form of a fragment of an SQL statement that limits the results returned. They're added to the SQL command built by Content Manager OnDemand, before it is sent to the database to be executed.		Query restrictions are created inside Group definitions. They take the form of a fragment of an SQL statement that limits the results returned to a subset of the metadata in the table. They're added to the SQL command built by Content Manager OnDemand, before it is sent to the database to be executed. Query restrictions are applied to users who are members of the group.

	== Examples ==		== Examples ==

Jderrick: Jderrick moved page Query Restrictions to IBM CMOD Query Restrictions: More accurate page totle.

2018-03-24T02:32:45Z

Jderrick moved page Query Restrictions to IBM CMOD Query Restrictions: More accurate page totle.

← Older revision

Revision as of 02:32, 24 March 2018

Jderrick: Initial Edit. Needs screen caps.

2015-06-29T06:20:33Z

Initial Edit. Needs screen caps.

New page

There may be situations in which you may want to restrict the range of documents that end users may have access to, without creating an loading that data into a separate Application Group and Folder.

== How Query Restrictions Work ==
Query restrictions are created inside Group definitions. They take the form of a fragment of an SQL statement that limits the results returned. They're added to the SQL command built by Content Manager OnDemand, before it is sent to the database to be executed.

== Examples ==

Let's say that you're a bank, and you want to prevent cashiers from seeing data from customers from outside the branch. You could add a new Group called "Branch 1234" and create a query restriction like this:

BRANCH_NO = 1234

And then add the users from that branch to that group. When members of that group ('branch') perform searches in OnDemand, the "BRANCH_NO = 1234" term is added to the SQL statement without the end user seeing it, restricting the search results.

In another case, you may want a regional manager at the bank to be able to have access to all customer data for bank branches in their region. Another new group might be called "Eastern Branches" with the following SQL fragment:

BRANCH_NO IN (1234, 1235, 1236, 1237, 1238, 1239)

This provides the regional manager access to reports from 6 different branches, without needing to define a 'region' field in the Application Group.

== Performance ==

Obviously, there is a performance implication, as you are making the SQL statement more complex. You can help reduce the impact of Query Restrictions on search performance by indexing that field in the Application Group -> Field Information tab.