in a real world scenario I have to implement three different operator groups named "supervisor", "manager" and "associate".
Each operator group has different rights to implement a marketing plan, program and campaign:
The supervisor is allowed to define everything.
The manager is allowed to define programs and campaigns.
The associate is allowed to define only campaigns.
At the moment I have implemented every operator group. That was without any difficulty. Now I have to define the differnt rights to each group.
To do that - in my opinion - I have to define named rights by myself. That would be without any difficulties as well. But how can I match the defined named right with the function "create/delete a new plan/program/campaign"?
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.
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...
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:
Is allowed to manage a...
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?
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.