This page (revision-12) was last changed on 26-Nov-2021 10:22 by jmyers

This page was created on 26-Nov-2021 10:22 by Administrator

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
12 26-Nov-2021 10:22 2 KB jmyers to previous RSTRCT_INCL_NULL ==> RSTRCT_INCL_NULL(System_Preference)
11 26-Nov-2021 10:22 2 KB RForbes to previous | to last
10 26-Nov-2021 10:22 1 KB JEscott to previous | to last
9 26-Nov-2021 10:22 1 KB JEscott to previous | to last
8 26-Nov-2021 10:22 1 KB JMyers to previous | to last
7 26-Nov-2021 10:22 1 KB JMyers to previous | to last
6 26-Nov-2021 10:22 1017 bytes JMyers to previous | to last
5 26-Nov-2021 10:22 975 bytes JMyers to previous | to last
4 26-Nov-2021 10:22 822 bytes JMyers to previous | to last
3 26-Nov-2021 10:22 684 bytes Administrator to previous | to last
2 26-Nov-2021 10:22 695 bytes Administrator to previous | to last
1 26-Nov-2021 10:22 156 bytes Administrator to last

Page References

Incoming links Outgoing links
IMSV
IMSV

Version management

Difference between version and

At line 2 added one line
[{Image src='IMSV.JPG' width='360' align='right' link='attach/IMSV/IMSV.JPG'}]
At line 3 changed one line
Data security is handled using the IMSV function. This is used to control access to subsets of data on the forms and tables. For example, you can restrict by user, which department codes that user can have access to.
text on form
At line 5 changed 19 lines
When specifying AUTHAREAMATCH in IMSV, ensure that in your value parameter, you have a trailing % (i.e. PW%). Although the People Selection list and some reports will append the % themselves, there are other reports and external access through our secured views do not append the %. As a result, an AUTHAREAMATCH of PW will result in NOTHING being selected.
The definition data for the Assign Security Rights screen is stored in the [P2K_AM_SECURITY_VALUES] table.
;[User|USER_NAME]: This field identifies the individual to whom the security right is being assigned.
;[Role|ROLE_NAME]:This field identifies the role the security right is being assigned to.
;[Security Right|SECURITY_RIGHT_CODE]:This field identifies the security right you wish to assign to the user/role. i.e Entity, AuthArea, Group
;[Look Up Value|DRV_SECURITY_VALUE_LK]: This field allows the user to select the value the security restriction applies to. The values in the LOV will be derived automatically based on the [Security Right|SECURITY_RIGHT_CODE] selected. For example, if Entity was selected in the [Security Right|SECURITY_RIGHT_CODE], the Look Up Value will be all of the defined Entities in the application.
;[Rule|SECURITY_VALUE_RULE]:This field identifies the rule associated with the security value, for example, 'Restricted To' or 'Restricted From'.
;[Security Value|SECURITY_VALUE]: This field will display the [id|ID] of the security value selected in the [Look Up Value|DRV_SECURITY_VALUE_LK] field.
%%warning
Note that setting lexicon values up to have restrictions means that not only will the user be restricted to/from the values noted when setting the field value, but that they will also be able to see the records that contain the values they are allowed to see.
Unless you set the preference [RSTRCT_INCL_NULL(System_Preference)] to "Y", this means that your users will not be able to see records that have NO value set (NULL) as that is an ''unknown'' value which may contravene your security settings.
%%
----
![Notes|Edit:Internal.IMSV]
[{InsertPage page='Internal.IMSV' default='Click to create a new notes page'}]
;[FieldNameInHdr]:description
This page (revision-12) was last changed on 26-Nov-2021 10:22 by jmyersTop