Designing a Workflow Engine for nopCommerce CMS Part 6: Security

This is Part 6 of a seven-part series describing how to implement Workflow Engine for nopCommerce CMS. Click here for Part 1
We've now got most of the Workflow tables defined, but we are still missing a few things.
One of those things is a definition for exactly who can perform Transitions; we're going to add SubjectToAcl att to the transition model and use nopCommerce AclRecord table for our Security

namespace DevPartner.Nop.Plugin.Core.Models.Workflow
{
    [SystemName("Transition")]
    [SubjectToAcl]
    public class TransitionModel : DPModel
    {
        [DataSource("../*[@type='State']")]
        [Required]
        [ShowOnListPage]
        [EditorTemplate("DropdownList")]
        public int FromState { get; set; }
        [DataSource("../*[@type='State']")]
        [Required]
        [ShowOnListPage]
        [EditorTemplate("DropdownList")]
        public int ToState { get; set; }
        [DataSource("System/Workflow/Action")]
        [ShowOnListPage]
        [EditorTemplate("DropdownList")]
        public int? Action { get; set; }
        [DataSource("System/Workflow/Activity")]
        [EditorTemplate("SuggestionList")]
        public int? Activity { get; set; }
        [DPParent]
        public WorkflowModel Parent { get; set; }
    }
}

What did we accomplish?

In this part, we nailed down exactly who could perform Transition by adding SubjectToAcl att.
In the next part of this series, we get to the real meat of the system. We'll show how individual Entity can track which Actions can be performed against them, and we'll see how we can use that list to determine which Transition the Entity needs to follow. Next up is Part 7 of this series, The Process table and Shortcomings.