Understanding Row Security

Row security enables you to secure users from accessing a particular range or list of data in any table. Use row security sparingly because it can adversely affect system performance. Additional processing occurs for each data item that you set with row security.

You can set up row security at three levels:

  • User

  • Role

  • *PUBLIC

EnterpriseOne looks for row security first at the user level, then at the role level, and then at the *PUBLIC level. If you set any of the security at a higher level, such as at the user level, the software ignores lower-level security settings, such as the group or *PUBLIC levels.

Before you set up row security for an item in a table, you should verify that the item is actually in that table. For example, the F0101 table contains the data item AN8. Therefore, you can set up row security for that item. However, the same table does not contain data item PORTNUM. Setting row security on this item for the F0101 table has no effect.

You set up row security on a table, not on a business view. You should verify that the object that you want to secure uses a business view over a table containing the object. For example, the Work With Environments application (P0094) uses business view V00941 over the F00941 table. You could secure the data item RLS (Release) because it is in the F00941 table. On the other hand, the same item is not in the F0094 table. If you attempt to secure the item on the F0094 table, data item RLS is not secured.

Note: You can find the tables, applications, forms, business views, and so on that use a data item by launching the Cross Reference application (P980011) after you build cross-reference tables (F980011and F980021).