You can use record level access control inside Manage | Security to keep a record from being editable. You can use a portal filter to omit records that you don't want the user to see and keep them from tripping error message when they try to edit such fields or getting "access denied" screens over the data.
But I'm a bit confused as to why you'd want to create an empty portal row by hiding the data and yet leaving the record in the portal. That suggests that there's more to this issue than you've currently described.
You can set row level restrictions based on a calculation in the security settings of a privelege set that could prevent edit.
As mentioned by PMJ above.
You could then detect record level access permissions with Get ( RecordAccess) to obfuscate the data
woof, ok, I'm new here and not an advance programmer, although I can get around a bit =)
I have a portal that has numbers in it that need to stay there for calculation purposes, - I'm trying to set up an account for a new office helper that will hide the data and lock certain portal rows from them.
the first screenshot is the portal
the second screenshot is what opens when one of the portal rows is clicked on, so I'm trying to restrict access to viewing the portal info #1, and #2, not being able to open the 'window' with all the information in it.
Your script that opens the window can use Get ( accountPrivilegeSetname ) to check the privileges of the current user and not open that window if the user is not allowed to open it. You can also use Hide Object When to hide the button whenever the current user's privilege set name is not one that indicates permission to open that window. That will block your office helper from being able to click the button in the first place.
With regards to #1. What data in that screen shot should be hidden from your new office helper? The entire row of data? if so, use a filter to omit the record. If not, Hide object when can hide specific fields from view.
Many thanx, I'm getting a bit closer, thanx to you and coherentkris helping a newbie.
I was hoping there was one place where I could turn it all off, but it's a bit deeper than that.
I have to look at all the instances of the tables/fields that I want to restrict.
And yes, the Get (accountPriv...) is helpful as well as the 'hide object when'.
Again, many thanx
1 of 1 people found this helpful
A general "road map" for your journey:
Inside Manage | Security, you can edit a privilege set such that you can control how users with that privilege can view and/or edit information in an entire record of a given table with calculations that evaluate as True or False. You can further refine this at the field level by controlling which fields can be viewed and which Modified--but these settings are for the entire table and can't be customized with a calculation.
This sets up limitations that apply to your entire solution. You can, to a degree, "turn off" things for a given group of users for the whole file BUT, the results can be much less than perfectly user friendly. Users that encounter limitations set in their privilege set can get hit with error messages and layouts were data is covered by "access denied screens" for certain records or all records in the table.
So to "file down the rough edges" we then go in and use interface design techniques to steer users away from things that they are not permitted to see in order to enhance their user experience. You can steer them away from layouts designed for use by higher level access users, for example. And any find that you perform will automatically omit any records that the user is not permitted to see. Portal filters and "hide object when" settings are additional UI tools to help keep the user inside their designated bounds.
So to sum all that up. Your security settings in Manage | Security are there to make sure that the user can't get to or modify data for which they are not permitted. It's the "Insurance policy" that makes sure of that even if the user finds a way past some unintended loop hole in your interface design.
securing your data is always "deeper than that".
welcome to FM