The AOSAuthorization table property enables you to specify which data access operations must undergo user permission checking.
The four fundamental data access operations are create, read, update, and delete.
No permission checking is done when the AOSAuthorization property is set to None.
Ex: Suppose AOSAuthorization is set to CreateDelete on a given table.
In this case, create and delete operations would be allowed to execute only if the Application Object Server (AOS) can confirm that the user has the appropriate permissions.
Update and read operations would execute without checking user permissions, because they are not mentioned in the chosen AOSAuthorization value.
The AOSAuthorization property also applies to views.
Ex: For example, suppose view Vew2 reads data from table Tab3. You have no read permission to either Vew2 or Tab3. The AOSAuthorization value on Vew2 is None, but on Tab3 it is CreateReadUpdateDelete. When you try to read from Vew2 the outcome will be a successful retrieval of data.
The four fundamental data access operations are create, read, update, and delete.
- None (Default)
- CreateDelete
- UpdateDelete
- CreateUpdateDelete
- CreateReadUpdateDelete
No permission checking is done when the AOSAuthorization property is set to None.
Ex: Suppose AOSAuthorization is set to CreateDelete on a given table.
In this case, create and delete operations would be allowed to execute only if the Application Object Server (AOS) can confirm that the user has the appropriate permissions.
Update and read operations would execute without checking user permissions, because they are not mentioned in the chosen AOSAuthorization value.
The AOSAuthorization property also applies to views.
Ex: For example, suppose view Vew2 reads data from table Tab3. You have no read permission to either Vew2 or Tab3. The AOSAuthorization value on Vew2 is None, but on Tab3 it is CreateReadUpdateDelete. When you try to read from Vew2 the outcome will be a successful retrieval of data.
No comments:
Post a Comment