On the Screen name properties, Screen descriptions and Access rights tabs, which are present when you have selected a new or existing screen file (not to be confused with a screen reference) in the Application browser, you may view or set a small selection of screen file properties. All screen file properties however, can be set in the Screen editor while editing the screen. See the Helps topics for these properties in the chapter about the Screen editor (Screen design) for more information.

Here you determine the access rights for this screen file to restrict access to it, dependent on the user (login name in Windows) and its assigned role.
The information in the Access property here, is the same as on the Access tab in the Screen object properties window for this screen opened in the Screen editor. Changes here or there are reflected on the other properties tab.

Click here for information on how to edit screen object properties in general.

Access (Role, Access rights)

Here you may define which Roles have which Access rights to this screen. You can indicate for each role whether no access (None), Read access, Write access or Full access must apply. No access means the screen won't be visible at all; Read access allows the user to view data on the screen but not to edit it; Write and Full access allow the user to edit the data on this screen.

None and Read have priority over the unmarked Read-only option for a screen, meaning that the Read-only option only makes a screen editable in principle, but that you can still exclude certain users from doing that, through access rights. These two access rights also have priority over less limiting access rights set on other levels in the application or databases.
If a role is not linked to this screen, then each user linked to that role has full access by default, unless restricted by other limiting access rights. A user without a role always has full access.
Users are assigned to roles, in the application setup.

Note that setting access rights on screen level is rarely put to use, since there are better ways to prevent certain data from being edited or viewed, for instance by using application identification roles, or setting access rights on database field level (see the reference below for more information).

See also

Security in Collections