Role.AutoAssociationPermissions Property

Specifies, whether or not the required permissions are automatically configured for associated objects/collections.

Namespace: DevExpress.Persistent.BaseImpl.EF

Assembly: DevExpress.ExpressApp.Security.EF6.v23.2.dll

NuGet Package: DevExpress.ExpressApp.Security.EF6

Declaration

C#

[DefaultValue(false)]
public static bool AutoAssociationPermissions { get; set; }

VB.NET

<DefaultValue(False)>
Public Shared Property AutoAssociationPermissions As Boolean

Property Value

Type	Default	Description
Boolean	false	true, if permissions are automatically configured for associations, otherwise, false.

Remarks

When the AutoAssociationPermissions value is false, you should manually grant permissions to both ends of the association, as demonstrated in How to: Manually Configure Permissions for Associated Collections and Reference Properties. When the AutoAssociationPermissions property is set to true, it is sufficient to grant or revoke permissions to view or edit a reference or collection property at one end of the association, and the Security System automatically adjusts the settings for the other end of this association. The default value is true, so permissions are automatically configured for associations. However, in certain complicated scenarios with conditional permissions, you may want to disable this feature, and configure permissions for both sides of an association manually.

The AutoAssociationPermissions value can be set in the entry point of your application, e.g.:

• in the constructor of your platform-agnostic module located in the Module.cs (Module.vb) file;
• in the constructor of your application located in the WinApplication.cs (WinApplication.vb) or WebApplication.cs (WebApplication.vb) file;
• in the Main method of the WinForms application located in the Program.cs (Program.vb) file, before the WinApplication.Start call;
• in the Application_Start method of the ASP.NET Web Forms application located in the Global.asax.cs (Global.asax.vb) file, before the WebApplication.Start call.

This is how the AutoAssociationPermissions setting is treated for various data model structures and scenarios:

Non-aggregated associated reference and collection properties

• If the Read type permission is granted, the Read member permission for the associated member will be granted automatically.
• If the Write type permission is granted, the Write member permission for the associated member will be granted automatically.
• If the Read member permission without criteria is granted, the Read member permission for the associated member will be granted automatically.
• If the Write member permission without criteria is granted, the Write member permission for the associated member will be granted automatically.
• Member permissions with criteria and object permissions are not handled due to their technical complexity.

Aggregated collection properties

• If the Read type permission is granted, the Read type permission for the associated member type will be granted automatically.
• If the Write type permission is granted for the parent object type, the Write, Create and Delete type permissions for the associated member type will be granted automatically.
• If the Read member permission without criteria is granted, the Read type permission for the associated member type will be granted automatically.
• If the Write member permission without criteria is granted, the Write, Create and Delete type permissions for the associated member type will be granted automatically.
• If the Read member permission with criteria is granted, the Read type permission for the associated member type will be granted automatically.
• If the Write member permission with criteria is granted, the Write, Create, Delete type permissions for the associated member type will be granted automatically.
• Object permissions are not handled.

Important

Limitations

• Aggregated reference properties are not handled.
• Member permissions for more than one property including an associated member (the “;” character is used to separate multiple property names) for the other side of an association are not processed, except for aggregated associations. For instance, in our MainDemo app, there is the Department class that has a one-to-many association with the Contact class through the Contacts collection property. If you grated a member permission for the Contacts property, and the other side of the association (Contact) already defines a member permission based on the associated member (Department) and other properties at the same time (e.g., Members = “Department;Manager;NickName”), then this case will not be handled and no permissions will be granted automatically for the other side of the association.
• Cases where more than one target member permission is defined for one side of an association are not handled, except for cases where more than one target member permission is defined on the associated side of the aggregated object.
• Cases where more than one equal target type permission is defined for one side of an association are not handled.

Note

In EF, any reference or collection property is considered as associated by default.