Hi,
When creating a custom access level, what is the difference between application rights and content rights?
There is a edit query right and there is a edit object right for Content>Web Intelligence and Application>Web Intelligence.
All of these three seem to have the same effect. So, which one should one apply for creating custom access level with edit query and no save rights.
ajq
anushajq (BOB member since 2005-02-22)
This is one of the most common points of confusion regarding the XI security model, but think of it literally. The application rights control what you can do with the application, regardless of which specific document. Content rights control what you can do with a particular document / folder, regardless of what application rights you have.
Start simple. Say you give broad WebI application rights (along with a minimum view / data access for a universe and connection), and the user creates a document. Where would they save the resulting document? By default, to their own personal folder (favorites), but to no other folder unless granted. Now think about documents in existing folders. Whether they have edit, schedule, etc. rights within that folder is controlled by content rights.
Does that help?
Dwayne Hoffpauir 
(BOB member since 2002-09-19)
Thanks a lot, that helped.
So, to clarify a bit further, is the Application level rights at a higher level than Content level rights.
So, if I enable “edit object” at Application level, does it enable edit query on ALL webi reports and this is different from “edit object” at Folder and document level which is for a specific folder and documents under it ( content rights).
It seems like edit objects at all levels has the same affect - enables edit query button but the difference is
at what level - whether for all reports (app level) or specific reports.
So, is it necessary to do edit object at Application level as that would be too permissive and only do edit query at content level.
Is this understanding correct?
anushajq (BOB member since 2005-02-22)
Honestly, I’m not exactly sure what the “edit object” right really means for the WebI application object. Focus on the WebI specific rights, not the General rights, on the WebI application object. Things like create documents, rights for Java Report Panel, other viewers, etc.
Period, now a new and separate thought … rights on folders / documents. Set edit, schedule, etc. rights as needed.
Now the interaction between them … think most restrictive wins. If you have edit rights on a document, but have no application privileges for any report panel, then you can’t edit. Vice versa is true as well. To actually edit, you need both. Make sense?
Dwayne Hoffpauir (BOB member since 2002-09-19)
Yes it does…thanks!
anushajq (BOB member since 2005-02-22)
Does anyone have any advice on setting up a security model that allows access to a high level folder and subfolders to a parent group, and access to particular sub folders to sub groups? (I have read security for mere mortals by the way). Example folder structure:
Members of the Parent Company group should be allowed to see all content in the Parent Company Folder and all subfolders. Members of the Company A Group should be able to see their folder content only (i.e. not B).
If I use a group hierarchy, for example:
Parent Company Group
|_Company A group
|_Company B group
and then create associations between each group and the required Access Levels on their corresponding folder I only partially achieve my goal because as Company A Group is a member of the Parent Group it inherits all of the Parent Groups rights and can see Company B Groups folder content.
However, if I dont create a hierarchy (i.e. a flat group structure), then I face the maintenance overhead of having to allow Company A Group and Company B Group the ability to traverse the Parent Company folder in order to get to their folder. This has to be defined on the Parent Company folder for each subgroup.
I havent complicated the issue with access levels so far, but I also have custom access levels for different categories of users.
Is this solution to have another Access Level that grants view access to this level only and associate this with the relevant folders and groups?
i.e. Is this what security for mere mortals is getting at…I should have 1 set of Access Levels for determining application functionality (e.g. a developer one, a casual user one etc) and another set of Access Levels for determining Content access?
Type2 (BOB member since 2009-07-08)
EXACTLY! And there is a custom access level described in the presentation that will do exactly what you need. Look at the one called “View folder only.” Assign this level to Everyone at the Parent Company folder level. This allows the user to see the Parent (required), but NOTHING below it. Now assign other roles to specific groups on specific folders. They can see ONLY that folder and below.
Dwayne Hoffpauir (BOB member since 2002-09-19)
Am I missing something? I understand the application groups and the folder access groups.
What I don’t understand is the “everyone” groups access to the top level folder. I have a Finance folder below the “Public Folder” by default “everyone” can view that folder - until I switch access off at the sub-folder level. That can’t be right can it?
I looked at this - does this also apply to the “Public Folders” as well? If so how do I set it so that everyone has view access to the public Folders only and nothing below it?
thankyou for your patience.
banshee (BOB member since 2009-11-20)
this post could help you
Indeed you need to give the right to view object at the top level folder and apply it only to folder…
Yes, thankyou I saw that post.
So the process would be:
But when I view the security of that folder it says it is applied to sub folders too.
I am quite confused by this.
banshee (BOB member since 2009-11-20)