Using IDO Filters to Limit User Access

You can restrict the data that the user can see by placing 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.

WARNING: 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.

Accessing IDO Filters

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

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

Creating and Maintaining IDO Filters

To construct or maintain IDO filters from the Row Authorizations form:

1. In the IDO field, specify the IDO to be filtered. This populates the Properties drop-down list.
2. Optionally, specify either the User or the Group to restrict the filter.
3. Specify the Property that will be filtered.
4. Specify an Operator to use to compare the property with the value.
5. To specify a value, choose one of these options:
   • Filter according to the current login, that is, the property is compared directly with the current user ID.
   • Filter with a literal value, which you enter in the field next to this option. (Null is a valid literal value.)
   • Filter by joining to a table that maps the User ID to some value(s). For example, this is useful for associating login IDs with other IDs such as customer number, salesperson ID, or vendor number.
6. If you chose to join to a table, select the mappings:
   • Select a table from the drop-down list. This populates the two fields below it.
   • Select the column containing user IDs.
   • Select the column containing the value to be filtered against.
7. Click Add This Clause. The pseudo-SQL for the WHERE clause displays in the field at the bottom of the form.
8. To add more clauses to the filter, start again with step 1 and continue through step 6. If you want to set up this new clause as an OR Instead of AND with the Previous Clause, select that check box. Click Add This Clause.
9. When the IDO filter is complete, save the record.
10. When you are ready to activate the filter on the IDO, select Active and save the record again.
11. Whenever you create or change a filter for an IDO, you must unload metadata from the IDO Runtime on the utility server.

Examples

For several examples of how to set up IDO filters, see Examples: IDO Filters.

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:
  • The general IDO filter, where both User and Group are blank
  • The user's IDO filter, where User equals the current login
  • The user's group's IDO filters, where Group equals 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 may 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.

Related Topics

Examples: IDO Filters

Assigning Users to Groups