Expand my Community achievements bar.

We are excited to introduce our latest innovation to enhance the Adobe Campaign user experience — the Adobe Campaign v8 Web User Interface!
SOLVED

Removing access to Global, Shared folder contents

Avatar

Employee

I don't know if anyone is still listening but I could not figure out the following:

 

Optional exercise, Administration Student Lab Handbook, Pg. 9

 

As your partition user, go to the Deliveries folder in your partition and create a new Delivery.

 

  • What Delivery templates are available? [Hint: You must use the folder icon twice to find all possible choices.]
  • How could we modify the security configuration so that users only have access to Delivery templates in their partition?
1 Accepted Solution

Avatar

Correct answer by
Employee

Your partition user only sees the Delivery templates folder in the partition because we have restricted their view to folders within that partition.

However, when that user goes to create a new delivery, he/she can browse (using the folder icon next to the Delivery template input field) to Delivery templates in the global, shared Resources\Delivery templates folder, based on membership in the Delivery operators group.

So even though we are restricting the view, the contents of any folders that the user has rights on are still available. If that user were to create a workflow, the Query would have access to any Recipients left in the global, shared Profiles and Targets > Recipients folder, even though that folder is not in their view.

There are several ways of preventing them from having this access:

  • One is to modify rights on the global, shared folder so that the out-of-the-box functional Operator groups (that we are using in order to get our security model correct with respect to behind the scenes Administration folders and global folders we do want them to see in order to perform their job tasks) no longer have access. This approach is discussed in the training.
  • Another is to use something called a System Filter (sysfilter) in the schema definition which restricts access at the schema level according to the security model.
  • Still another is to export the security model we have created and hand edit the XML so that all rights needed are directly associated with our custom Operator group.

These last two approaches are beyond the scope of this particular class, which is more to familiarize the student with the security model, but more details of these alternate solutions should probably be part of an advanced training or the subject of a Tech note in the wiki.

View solution in original post

1 Reply

Avatar

Correct answer by
Employee

Your partition user only sees the Delivery templates folder in the partition because we have restricted their view to folders within that partition.

However, when that user goes to create a new delivery, he/she can browse (using the folder icon next to the Delivery template input field) to Delivery templates in the global, shared Resources\Delivery templates folder, based on membership in the Delivery operators group.

So even though we are restricting the view, the contents of any folders that the user has rights on are still available. If that user were to create a workflow, the Query would have access to any Recipients left in the global, shared Profiles and Targets > Recipients folder, even though that folder is not in their view.

There are several ways of preventing them from having this access:

  • One is to modify rights on the global, shared folder so that the out-of-the-box functional Operator groups (that we are using in order to get our security model correct with respect to behind the scenes Administration folders and global folders we do want them to see in order to perform their job tasks) no longer have access. This approach is discussed in the training.
  • Another is to use something called a System Filter (sysfilter) in the schema definition which restricts access at the schema level according to the security model.
  • Still another is to export the security model we have created and hand edit the XML so that all rights needed are directly associated with our custom Operator group.

These last two approaches are beyond the scope of this particular class, which is more to familiarize the student with the security model, but more details of these alternate solutions should probably be part of an advanced training or the subject of a Tech note in the wiki.