If you have used SmartTarget, you will probably know that the security model for managing promotions is pretty basic – you either have rights to manage promotions or you don’t. On my current implementation we have different business units managing their own SmartTarget promotions for various sites and applications, all within the same CMS, so all able to view, edit (and accidentally break!) each others promotions. This post shows a simple solution we came up with to ensure each user could only manage appropriate promotions.

The key to the solution is that each business unit (BU) manages promotions for a separate group of SmartTarget regions, and we use a naming convention for these regions (something like {BU}.{Channel}.{RegionName}, for example Sports.Web.Start and Sports.App.Dashboard for content areas on the Sports Website Start page and Sports Mobile App Dashboard screen).

If we can filter the list of regions shown in the SmartTarget UI by using the appropriate BU prefix when creating promotions, then a BU would only be able to create promotions using their own regions. We would then be able to filter the list of promotions to only show those set up for regions valid for that BU.

Filtering data shown in the GUI is pretty simple – you just need to implement a DataExtender GUI Extension to rewrite the XML in the ProcessResponse method, and add this as a Model extension.

In the example above, we are simply hard-coding the list of region prefixes to filter on, but we actually want to have that configurable depending on the user. This was pretty simple to set up too – by using Tridion Groups with a special naming convention. For each BU we create a Tridion Group with name in the form Promotion Manager [Region Prefix Sport]. When processing the request in the Data Extender we read the current user’s group membership (using the Core Service) and work out if they are in any groups of this type. If so, we load in the prefixes and use these to filter the promotions and regions shown:

Note that we also check if the user is an administrator, and if so, skip the whole filtering process. In the example above the CoreServiceHelper class is a simple helper class which handles the connection to the CoreService – its not the aim of this post to explain this, and you probably have your own library for doing this, so I am not putting the code here.

I’m not going to go into the details of how to create an install a Data Extender GUI Extension itself as this has been covered in other posts, such as this excellent one by Jamie. Its probably only worth noting that this extension is a Model extension, rather than an Editor extension and the Model.config configuration is as follows: