Category Level Security for Views

Tobias Grempel shared this idea 7 months ago
Completed

Hi,

There looks to be an issue with how view security is being applied at the content category and sub-category level.

In terms of editing and/or deleting views, access security is being applied so users or groups can only edit/delete if they have the appropriate level of access, but there is still the issue of visibility.

Although a content category/sub-category could be hidden completely from a user or group, they can still see the view if they click on the 'All' grouping in the Browse section.

Are there plans to update this access control so that it matches with security for other content such as reports or dashboards.

To replicate this issue follow these steps:

  1. Create or edit a view
  2. Save the view in a secured category/sub-category
  3. Log in as a user without access to that category/sub-category
  4. The category/sub-category won't be visible, but the view is still visible if you click on the 'All' grouping.

This issue is found in all newest builds of 7.4, 8 and 9.1.

Comments (12)

photo
0

Hi Tobias,

I apologize for the delay in my response regarding this behavior.

I have been able to replicate this within 9.1 and our latest version, 9.2. I should note here, Reports, Dashboards etc will not show up in the same manner as views and do not populate the message 'Folder Security does not apply to Views saved into secure folders.':

/b93de580f088057f3b2b2f034569aef2

Regarding this, there seems to be some confusion around the behavior internally and how we should address it. I will reach out to my team and gather a consensus on what to do here.

I am leaning towards raising this as an enhancement to our devs. To do this would it be possible to get a written use case from your end for this functionality?

Please let me know.

Thanks,

Jared

photo
0

Hi Jared,

we are seperating different permissions through grouping in Yellowfin. Now I tryed to name the groups after the forms our users have permission to. But they are restricted with workflow. But now, when they see different forms from the ones they work with, they could use them in the browser to go there, even if they are not permitted. Because they see the formnames in All diretory in Yellowfin.

That's a problem and even if I don't name the views after our forms. They can see to much details from other workingspaces. But it would be a first workaround, that they can't get directly there in Yellowfin.

Kind Regards

Tobias

photo
0

Hi Tobias,

Thanks for providing this use case for this.

With this use case I can approach our team and review what our options are here.

Have you reached out to BMC regarding this behavior? Due to significant environment variables as a BMC client, inquiries should generally be directed to their support staff. http://www.bmc.com/support/support-central.html.

This will ensure we keep all of our bases covered and bring to light potential fixes provided by their team.

Please let me know if you have any questions or difficulties reaching out to the BMC team.

Thanks,

Jared

photo
0

Hi Tobias,

I wanted to reach out to see if you have been able to get a hold of BMC regarding this.

Please let me know if you have had any issues in doing so.

Thanks,

Jared

photo
0

Hi Jared,


it's not an issue for BMC, the only problem is in Yellowfin. In "All" folder every view you create is visible for every user in Yellowfin. That is the main problem. Because there all users can see all other views and so I can't name them after our forms. Because we can't hide the names in the weblink.


Sorry, my answer took so long, I was on holidays.


Regards


Tobias

photo
0

Hi Jared,

I don't know why you still waiting for a reply?

BMC can't do anything besides crypting the browserlink to solve the problem. With that we had a ticket long ago.

Regards


Tobias

photo
0

Hi Tobias,

I understand that the issue is within Yellowfin and not with BMC.

We are happy to help investigate any issues client may encounter, However BMC needs to be aware of any issues for contractual reasons.

As far as this functionality we are encountering expected behavior as folder security does not apply to views. We can raise an enhancement request to our development team to look at getting this behavior changed. To do this we will need a written use case from your end to attach to the enhancement request.

Please let me know if you would like to pursue an enhancement request.

Thanks,

Jared

photo
0

Hi Jared,

we are happy, that you help us investigate. The problem is not the folder security in general. All folders I created work perfectly fine. It's the problem that the "All" folder is visible, can't be hide and can't be security changed.


For example, I create a view for the group "LiMa" and create a folder with this group policy. Then I create a view for "Oracle" and create a folder with this group policy. If I now get the permission group "LiMa" to a User he sees only the "LiMa" folder and view. And the other way round. But they both see all views created in the standard YF "All" folder. But I cant restrict this folder.


If I made a ticket at BMC for that the 100% answer is, not our problem. Why do you come to us with that issue.

Thanks,

Tobias

photo
0

Hi Tobias,

I'm taking this over from Jared as he's out this week. I'm looking into this and I can see that what you're requesting has been requested by others before as well. Right now, this request is still being considered and debated as it will require major changes. That said, I've gone ahead and added you to the client list in that task and linked this ticket to said task so I'll be prompted to update you should further details and possibly an enhancement arise.

The other thing I can do is confirm with certainty that this is expected behavior and provide some insight into the details surrounding this. As determined by the dev team it is confirmed that "client[s] can access view regardless of their access to the containing folder." In fact, there used to be a warning message 'Folder Security does not apply to Views saved into secure folders', but it was removed because it was felt to be redundant.

One of the big reasons this has not been implemented yet is because this request to add view security access to match the containing sub-folder restrictions will have side effects. For example, for public reports created from a View stored in read-only folder (to some clients) - should clients be able to view reports while they have no access to the View? In addition, this change could potentially affect clients who currently set up view securities in their own profile. Some reports or views could vanish from their screen after the changes have been applied.

As you can see there are some pretty large considerations here and it may be a while before any commitment to making this type of change is actually developed and implemented.

The current solution for setting View access is you can set up access rights to views through the data source security, where you can specify which users can create/modify views related to that data source.

You set access to reports built on Views in the View Security tab on the Prepare stage when you're editing the View:

/6b69d35bbdc009cb725c431e5a57ea6b

If I just configured this above and logged in from System Administrator, I'd see the View in Browse as well as the reports created on the View, but from another user, I'd just see the View. There's currently no way to stop the View itself from showing up though, no matter the combination of Security settings.

Hopefully this explanation makes sense and clears some of this stuff up. Anyways, I'll keep you posted in this ticket on any future developments regarding this case.

Regards,

Mike

photo
0

Hi Mike,

thank you for the reply and the information. Maybe if you have an issue to put on the folder rights to the "All" folder. You can implement an option to make it invisible for some/all clients?

We are looking forward to your posts.

Regards

Tobias

photo
0

Hi Tobias,

Thanks for your response. I can't really speaks to specifics of implementation, especially since this is still being debated interanally, but I've noted this possibility in the task as well, so I'll have to see what the dev team comes back with.

Regards,

Mike

photo
1

Hi Tobias,

Just writing to let you know that 9.4, which contains this enhancement, has now been published. You can download the full installer here.

Here are the direct links to download the update installers: .exe / .jar

Please download and install and confirm the fix when you get the chance.

Regards,

Mike