Limit Access to Fields
Field security prevents unauthorized users from updating secured fields. It does not prevent them from seeing the value of a field if they have access to the screen where it is updated. Neither does it protect a field from program-level updates through custom code.
The system determines whether a user is authorized based on whether the user ID matches the values specified for the field. User groups are supported through a two-step process.
Field Security Validation
In the standard release, security is not active for any fields, and only a few fields are eligible for field security. Use the Dictionary Field Security Report (36.3.23.20) to determine which fields can be given security.
In the character and Windows interfaces, you can also access the field on a screen and press Ctrl+F. The information window indicates whether password validation is available for the field.
An eligible field must have a specific validation expression in the data dictionary. The expression must reference gppswd.v. The syntax is:
{gppswd.v &field=<dictionary field name>}
Activated Field Security Report
Use the Activated Field Security Report (36.3.23.19) to see which fields have security activated. It also lists privileged user IDs.
Dictionary Field Security Report
The Dictionary Field Security Report (36.3.23.20) lists the fields containing the association to the validation file as part of their definition.
Protect any of these fields from update by creating a record of privileged user IDs or groups. This association can be made to any field, and is one of the only database definition changes you can make that does not constitute a schema change.
Adding Security to an Eligible Field
1 Add the field name and the list of user IDs that can access the field in Field Security Maintenance (36.3.19).
2 Verify that the field is secured by running the Activated Field Security Report (36.3.23.19).
Adding Field Security Eligibility
You can make most fields eligible for field security by adding the validation expression to the field in the data dictionary. You then recompile the programs that use the field, using the modified data dictionary. It is not always possible to add field security. Some fields have preexisting data dictionary validation expressions that prevent the addition of gppswd.v.
Warning Once you have made a field eligible for field security, you cannot make it ineligible. You can deactivate the security by removing all user IDs for the field in Field Security Maintenance (36.3.19).
For multiple databases, make your security changes in the database against which you compile. The changes are then in effect for any other databases you run the compiled code against.
1 Identify and list all fields you want to add security to.
Since recompiles take time, it is more efficient to add all field security at once.
2 Make sure all other users are logged out.
3 Run Field Eligibility Maintenance (mgfldcmt.p, 36.25.22), which changes the validation expression and message in the data dictionary.
4 Set field security for each field on your list.
The mgfldcmt.p utility prompts for a table and field name on which to activate field security. Once you enter a valid field and table name and you press Go, you are prompted for the next entry.
5 Press End to exit Field Eligibility Maintenance.
6 Recompile either all programs or those programs impacted by the changed field security. If you have custom programs that access these fields, they also need to be recompiled.
To compile only the affected programs, make a backup copy of utcompil.wrk in the qad directory, and then delete the program names that you do not want recompiled from the file.
utcompil.wrk contains a complete list of all programs.
7 Back up recompiled code.
8 You can now add the field name and the list of user IDs that can access each field in Field Security Maintenance (36.3.19).
9 Verify that each field is secured by running the Activated Field Security Report (36.3.23.19).
Note: For multi-language implementations, you must run mgfldcmt.p in the base language instance. Then you must recompile your code for the base language and all other languages you have implemented.
Field Security by Group
You can also set up field security for a group of users.
1 Assign users to groups in User Group Maintenance (36.3.4) or User Maintenance (36.3.1).
2 Execute Field Security by Group (36.3.20). This function adds all users who belong to a specified group to the list of authorized users for a validated field.
Field Security by Group (36.3.20)
Even with this process, field security is only available at the user level, not the group level. Field Security by Group is simply a batch utility that lets you add multiple individuals simultaneously. This has the following consequences:
• If you remove a user from a group that was given access to a field, that user can still access the field. To prevent this, use Field Security Maintenance (36.3.19) to remove the individual user.
• You cannot use Field Security by Group to remove a group of users from the list of authorized users. To remove a group, you must remove every individual in the group in Field Security Maintenance.
• If you delete a group in User Group Maintenance, individual records remain on the system until you delete them in Field Security Maintenance.
Once Field Security by Group is executed for a field and group, all users who belong to the group display in Field Security Maintenance as authorized to access the field. The Comments field in Field Security by Group displays as the comment for the field and user combination in Field Security Maintenance.
