Security Views

The security views work by joining together the security join tables along with the OPRID of the user accessing the view. All security views share some characteristics both in their structure and their view text.

Each view must include the OPRID as a key field, the keys for the transaction data, and any additional fields that are used as search or list box fields. Most core views also include other fields from the security join record that other views can enter where criteria against.

We are not including ROWSECCLASS as a key in the security views. This is because if we do, then we would have to require a ROWSECCLASS be entered for every OPRID. The reason for this is that when the join to PSOPRDEFN is done behind the scenes, it will put the value of PSOPRCLS into the field returned from PSOPRDEFN.ROWSECCLASS if the ROWSECCLASS is blank. If the PSOPRCLS is also blank, then the OPRID is returned. This makes it impossible to join to the SJT_CLASS_ALL table. Including the ROWSECCLASS as a non-key field in the security view is okay, but does not provide any benefit. You will still find it in some views because it was less risky to leave it there for now.

The core views need to join in PSOPRDEFN, SJT_CLASS_ALL, and the appropriate transaction SJT. For example, for People with Jobs and/or People without Jobs the SJT record is SJT_PERSON.