Using IDO Filters to Limit User Access

To restrict the data that the user can see, you can place filters on the IDO. Any smart client or web client that accesses the application can view an appropriate subset of the data in the collection, based on the filters applied to the IDO. IDO filters can be general, that is, applied to the IDO when anyone accesses it, or they can be constrained by user IDs or groups.

For example, you can create a filter so that salesperson users can only view their opportunities and not those of other salespeople. Or you can create a filter so that your customers who log into the application through a portal can see limited information about their orders.

Use the Active check box to turn filters on and off as needed, for example, during testing.

Caution: By default, the Active check box is selected for all Infor-provided filters that are defined in the Row Authorizations form. If you turn off the Active check box for a filter, then any user who was previously restricted by the filter is no longer restricted. For example, if you turn off the Infor-provided filters that are set on the Interactions IDO, then any customer portal user can see ALL interactions in the system, not just the ones related to that customer.

You can access IDO Filters in the Row Authorizations form by any of these methods:

From the Explorer, open the Row Authorizations form.
From the Users form, click User IDO Filters or Group IDO Filters to open the form filtered on the selected user or group.
From the Groups form, click User IDO Filters or Group IDO Filters to open the form filtered on the selected user or group.
From the IDOs form, click IDO Filter to open the form filtered on the selected IDO.

Notes

When logged in as a super user, you always see unfiltered data.
When you display a collection on a form, you can tell whether IDO filters have been applied by opening the About This Form dialog box. Any applied filters are listed in the dialog box.
The IDO filter is an additional clause that is added to the pseudo-SQL WHERE clause which is transformed by the runtime into the SQL used to load the collection. The filters for an IDO are loaded with the rest of the metadata, so they are cached with the metadata objects. When the collection is loaded, the SQL command builder uses the metadata to add the IDO-level filter clauses to the WHERE clause, unless the load bypasses the filters (is loaded by a super user).
The IDO filter clause is built by ANDing together all or any of these filters:
- The general IDO filter, where both User and Group are blank
- The user's IDO filter, where User is set to the current login
- The user's group's IDO filters, where Group is set to any of the current user's group memberships. (The group filters are ORed together, since the user should be able to see the rows visible to any of the groups the user belongs to.)
Placing many individual user filters on an IDO requires a lot of setup and maintenance time for the system administrator. Where possible, include multiple users in a group or cross-reference table, and then apply the filter to the group or the table join.
Be aware that, when you use filters on IDOs that have multiple levels of IDO inheritance, or when you have users who are members of many groups that each have filters, the filter clauses can accumulate to the point where performance might suffer.
Look at the pseudo-SQL query that is produced. If any of the columns in the query are not indexed, it can affect processing time. Compare the pseudo-SQL query to the original query that existed before you set up Row Authorizations, to determine the outcome of the additional filtering. You can view the pseudo-SQL query in the Log Monitor utility or the IDO Runtime Development Server.