This registry entry enables you to make all instances of a particular type of record global (security id will be blank), regardless of the security of the user that created it. Note that a user will only be allowed to access those records defined by his user group.
Testing Your Registry Entries
The system does not verify the validity of registry entries. Be sure to test your registry entries after completing them to verify that they are functioning correctly.
Setting Values are Uppercase-Lowercase Sensitive:
The Setting Value is case-sensitive: be sure that you enter the value exactly as specified in the documentation. If the documentation specifies a value of true, do NOT enter True or TRUE.
Normally, the security of a record (e.g., branch or global) is determined by the security level of the user that creates it. For example, if Mary's security is set to 110 (her branch or division), all of the records she creates will be assigned the security id 110. If she needed to create a global record that everyone could see (e.g., a national vendor), one option would be to log in under a global security id.
Note that an alternative to using this registry setting is to implement multiple user securities, as discussed in the User Account Viewer in the User Security Table.
Id: sys-securityexceptionsbytable
Setting Key: ExceptionProperty Setting Value: IncludeOnly
If this option is included, the tables NOT listed in this entry WON'T BE subject to security logic. This enhancement allows the system handle the exceptions in one-way or the other...to provide additional flexibility in configuration.
If this option is specified, all tables listed in this registry entry (see the following option) will be included in the user’s security level. All tables not specified will be created as global (no security id). It is strongly recommended that you discuss this option with your support representative before implementing: changing your security methodology in midstream can lead to unintended consequences.
WARNING:
This option should NEVER be used in conjunction with the following registry setting:
Registry Id: sys-ffv-global-settings Option: SecurityOverrideFrom=job
Doing so can lead to undesirable results in your security setup.
tablename1,tablename2,....
The contents or additional contents fields should list only those database tables that should always be assigned global security (unless the ExceptionProperty’s IncludeOnly option described above is implemented). The internal table name must be used - a partial list of records and their corresponding table names follow:
Record Tablename
GL Account glaccnt
GL Entity glentity
Client clnt
Vendor vndr
Vendor Insurance vndrinsrnce
Vendor Contact vndrcntct
Note that the last two items on this list are child tables of the Vendor record. If you are implementing this registry entry, all applicable child tables should also be specified, otherwise the parent record will have global security and the child table will have the user's security (which may or may not be global). This situation can lead to undesirable results. We strongly recommend that you discuss your firm’s security structure with your Data-Basics support representative before implementing this registry option.