How do you block access to List All report for a role?

  • 0
  • 1
  • Question
  • Updated 10 months ago
  • Answered
I can hide the report in the reports list but need to know how to completely block access to the List All report from a specified role.
Photo of Ian` Turner

Ian` Turner

  • 366 Points 250 badge 2x thumb

Posted 10 months ago

  • 0
  • 1
Photo of Chris

Chris, Champion

  • 4,390 Points 4k badge 2x thumb

Go into the report's properties and set access to the roles you want to view it.

"May be viewed by " [select roles]

Photo of Ian` Turner

Ian` Turner

  • 366 Points 250 badge 2x thumb
This doesn't work - if you add ?a=q&qid=1 to the base table URL you can get the List All report even if you have set the 'May be viewed by' to block that role and also removed the report in the role settings 'Common Reports enabled'

The behaviour in the 'Common Reports enabled' settings was not what I was expecting - in that I thought that unchecking the report would have blocked access.
Photo of Evan Martinez

Evan Martinez, Community Manager

  • 9,214 Points 5k badge 2x thumb
If you want to go beyond just hiding a report from the list and make sure a specific role isn't able to open a report at all, that report has to contain a field that users in that role do not have access to.
Photo of QuickBaseCoach App Dev./Training

QuickBaseCoach App Dev./Training, Champion

  • 52,786 Points 50k badge 2x thumb
Can you clarify the business purpose of the question? Is your goal to prevent an employee from easily printing out the entire Customer list and going to work for a competitor, for example?

Do I assume that they still need access to that table to do their day to day job though?
Photo of Ian` Turner

Ian` Turner

  • 366 Points 250 badge 2x thumb
The situation you outline is pretty much correct - employees may need access to every row in a table on a 'single row at a time' basis, but the entirety of the data is commercially sensitive.
Photo of QuickBaseCoach App Dev./Training

QuickBaseCoach App Dev./Training, Champion

  • 52,786 Points 50k badge 2x thumb
Here are some ideas.

1. Use field level permissions to block access to certain fields.

2.Hide the Table to certain Roles so that these users will not know the Table ID# to append &a=q&qid=1 to

3. Move the table into a separate app and block access to that app for that Role.  But you can still have a cross app relationship to pull the data into child tables on lookups.  The permissions for a cross app relationships are set at the Advanced Properties tab for the source app and if the user does not have permission then these permission levels will apply - so that really is your more secure method.  I believe actually it is bullet proof as then those roles simply cannot guess their way to the table  or receive a link from a co-worker and gain access.
Photo of Evan Martinez

Evan Martinez, Community Manager

  • 9,214 Points 5k badge 2x thumb
Hi Ian,

If they need access to the individual fields but you are concerned about them seeing reports I would suggest making sure that users in that role can't make reports (Since they could then recreate any report they like) then I would make sure any report you want to be certain they aren't able to access contains a field users in that role are restricted from. What this does is make sure even if they use a URL or link they had previously that reports permissions will block them out. You can even just make a field named access that is restricted for any role you don't want to view a report and then add it to each report. This way if they try to open it the permissions will prevent them from viewing the report. Alternatively Mark's suggestions offer some other ways of altering your workflow to better protect your data. 
Photo of Ian` Turner

Ian` Turner

  • 366 Points 250 badge 2x thumb
Thank you for your suggestions, the field permissions give me a short term solution - though longer term I will suggest that the sensitive data is kept in an external app and accessed with cross-app permissions.

This will require some redesign though.