Hi Tomas,

Only CMS users that have publish permissions on the content have the option to create and manage A\B tests for items in the CMS. The thinking being that the B version of the content, which is in a draft state during the A\B test, will be live on the site so the user that creates the test for that content should be trusted to publish to the site (not to mention picking a winner will publish that version of the content).

I think it would be nice to be able to hide that functionality, so that only specific roles can set up / monitor see AB tests that are running. I get the thinking on Publish rights, but with our clients, it is only the more advanced digital marketers who would be using the AB test functionality 

That is a good point, I will write up the enhancement to include an A\B testing user group into the package for this type of use case. Thanks for the input!

Our team came up with a solution to this. Added this to BaseController, to set a value on the profile indicating if AB-testing should be available.

        protected override IActionInvoker CreateActionInvoker()
        {
            RestrictedUserCheck();
            ...
        }    

    private void RestrictedUserCheck()
        {
            if(System.Web.HttpContext.Current.User.Identity.IsAuthenticated)
            {
                const string restrictedUserKey = "no_ab_testing_for_you_mister";
                var profileRepo = ServiceLocator.Current.GetInstance<IProfileRepository>();
                var profile = profileRepo.GetOrCreateProfile(System.Web.HttpContext.Current.User.Identity.Name);

                // We only need this code to run once
                object profileValue;
                if (!profile.Settings.TryGetValue(restrictedUserKey, out profileValue))
                {
                    profile.Settings[restrictedUserKey] = !System.Web.HttpContext.Current.User.IsInRole("MarketingAdmins");
                    // Saving to the profile allows us to access this value in the client side UI
                    profileRepo.Save(profile);
                }
            }
        }

And then some hacky dojo magic, to update the UI based on the profile:

define([
// Dojo
    "dojo",
    "dojo/_base/declare",
//CMS
    "epi/_Module",
    "epi/dependency",
    "epi/routes",
    "dojo/when"
], function (
// Dojo
    dojo,
    declare,
//CMS
    _Module,
    dependency,
    routes,
    when,
    StoreInitializer
) {

    return declare("app.Initializer", [_Module], {
        // summary: Module initializer for the default module.

        initialize: function () {

            this.inherited(arguments);

            var profile = dependency.resolve("epi.shell.Profile");

            if (profile) {

                // Profile returns a promise so we wait for this before checking the value
                when(profile.get("no_ab_testing_for_you_mister"), function (restricteduser) {
                    if (restricteduser === true) {
                        // Get the global command registry
                        var registry = dependency.resolve('epi.globalcommandregistry');
                        registry._mappings['epi.cms.publishmenu'].providers.splice(2, 1);
                    }
                });
            }

            

            var storeInitializer = new StoreInitializer();
            storeInitializer.initialize();
        }
    });
});

And then register the javascript file in module.config

  <clientModule initializer="<path_to_the_javascript_file>
    <requiredResources>
      <add name="vendors-jquery" />
    </requiredResources>
    <moduleDependencies>
      <add dependency="CMS" type="RunAfter" />
    </moduleDependencies>
  </clientModule

The A/B-testing option is hidden from the publish menu, if the user is not added to the group MarketingAdmin.