These example implementations are NOT designed for the 'new' security system components (SecuritySystemUser/SecuritySystemRole or PermissionPolicyUser/PermissionPolicyRole) and their scenarios (e.g., middle-tier application server or SecuredObjectSpaceProvider) and thus this code should not be used "as is" with v15.2 or newer.
The Activity (scheduler appointment or event), Employee (scheduler resource or security system user) and Group (security system role) classes' code was once created based on the code of the default Event, Resource and security classes from our DevExpress.Persistent.BaseImpl library. We would like to avoid synchronization and maintenance problems for our users going forward, so it is necessary to update the code of the Activity, Employee and Group classes based on the ...\Sources\DevExpress.Persistent\DevExpress.Persistent.BaseImpl\ library sources (see the Event.cs, Resource.cs and the PermissionPolicy sub-folder files) according to changes made in the latest XAF versions (15.2+). The eXpressApp Framework > Task-Based Help > How to: Implement a Custom Security System User Based on an Existing Business Class help topic will be helpful as well.
This example demonstrates how to create fully custom classes for use in our Security Module (with the 'old' DevExpress.ExpressApp.Security.SecurityComplex component) and Schedule Module:
- Activity is an analog of our standard Event class that is used to represent appointments in the Scheduler Control.
- Employee is an analog of the standard User class, which also supports the IResource interface to use objects of this class as resources in our custom appointment above.
- Group is an analog of our standard Role class
To enable these two custom security classes in your application set the RoleType and UserType properties for the SecurityComplex component within the Application Designer.
Additionally, the two popular filtering tasks are implemented: filtering appointments by the current logged employee and also filtering resources to show only those owned by the current logged employee.
This functionality is provided by the SchedulerActivityListViewControllerBase class and its descendants as follows:
a. Administrator account (Sam, to log on, leave the Password field empty) sees all the resources and appointments in the root scheduler view.
b. Non-Administrator account (John, to log on, leave the Password field empty) sees only his own resources and appointments in the root scheduler view.
c. Both Administrator and Non-Administrator accounts see their own resources and appointments in the nested scheduler view.
You can use SchedulerActivityListViewControllerBase and related controllers for study purposes, since they demonstrate the most common filtering scenarios in the scheduler view. If you do not need all this specific functionality, simply remove these controllers and create your own ones (perhaps based on the provided example code) that will do only your specific task. For example, the controllers from this example are not suitable in the nested scheduler view because you miss some part of the default Link/Unlink functionality since the scheduler view is always filtered to show only its own resources and appointments.That may not be desired because you may want to have the capability to link appointments from other resources, but they won't be shown due to the above. Plus, these demo controllers are unnecessary for appointments filtering in the nested scheduler view, because by default, in this view only appointments from the current resources are shown.
The IEvent and IResource members are used for appointment and resource mappings and should be declared as public properties. Both XPO and Entity Framework consider public writable properties as persistent (mapped to database columns). If you want to map these properties to columns with different names, use the Persistent or Column attributes in XPO and Entity Framework correspondingly. Alternatively, you can manually calculate property values and decorate interface members with the NonPersistent or NotMapped attributes to specify that these properties are not mapped to columns in the database. If you do not want interface members to be visible in views, use the VisibleInListView, VisibleInDetailView, and VisibleInLookupListView attributes correspondingly.