Named Rights for Plans, Programs and Campaigns

I haven't tested it, but I believe you could use the INSERT, EDIT and DELETE FOLDERS named rights to control who can create Plans and Programs. Generally for most configurations, including Campaigns, you assign read, write and/or delete access on the folder containing the configuration, or on a parent folder. But it sounds like all of your groups can create campaigns.

One issue you will run into when creating custom Operator Groups is that there are a number of Administration folders that managers and associates will need r/w/d access to even though those folders are hidden from their Explorer view. The only way to get those rights is to use the out of the box Operator Groups or to configure this access. To configure this access from the UI would be prohibitive, so generally we export the Folder access rights of the out-of-the box groups and then adapt them for our custom Operator Group.

Let me know if you would like to use office hours for an interactive session, or we can continue the discussion here. It is a great real-world example/scenario.

Hi Linda,

thank you for your answer!

I already thought about using the INSERT, EDIT and DELETE FOLDERS named rights to control who can create Plans and Programs. But I am quite not sure, if I can use these named rights for this matrix:

If the manager owns the named right INSERT, he will be able to define plans. Is that right? But in the business need that would be wrong. :-(

In the preferred way I will do the configuration from the UI. I am awake of the Administration folders that managers etc. will need RWD access to. Do you think that is impossible? In this case: How can I export the Folder access rights and what do I have to do?

Kind regards,

Frank

  I will check with our internal consulting team how they would set up separate rights for Plans and programs.

For exporting the Folder access rights, you would create a Deployment package and export the Operator access rights on folders (xtk:rights) using the filtering condition Operator groups included in [the out of the box Operator groups that have the rights you are interested in, e.g. Campaign manager, Delivery operator...] Then in the XML package, replace those Operator group references (ids) with the id of your custom Operator Group.

You can also restrict UI functionality by making parts of a form available only for certain named rights. For example, if you look at the xtk:folder Form (not schema) you will see...

     <container applicableIf="HasNamedRight('folderEdit')"

...but let me ask if that is the right way to go about this.

Hi Linda,

I am curious about the information from the internal consulting team. It seems to be a non-trivial question. ;-)

In between I followed your advice to create a Deployment package and export the Operator access rights. I already started to analyze the XML-file, but there are some parameters I do not know.

• What is the difference between INHERIT and PROPAGATE?
  In my opinion the meaning is the same!? Inherit and propagate means that ancillary elements are going to get the right. Right?
• Can I associate that the value 1 always is true and the value 0 is always false?
• What does the attribute "_operation="none"" mean (see the tags for folder and operator)?
• The attribute "name" in the operator-tag represents the Operator group. I thought that the attribute "name" in the folder-tag represents the schema. But I did not find a schema like "nmsRootRecipient". Are such schemas a component of another schema?
• What does the type-attribute stand for?

I am sorry for all the questions, but I could not find any documentation about that and the Online trainings did not agree to the rights management in that detail.

Furthermore thank you for your support.

Best regards,

Frank

Hi Linda,

thank you for the information! I'm already very curious about the answer.

But now... Enjoy the public holiday! ;-)

Best regards,

Frank

Hi Linda,

I am sorry to ask further questions, but are there any GOOD news? ;-)

Best regards,

Frank