I have a (CRM) grid that has associated view (a) I need to add another associated view (b) to the same grid and to give different view permission (some users will see 'a' and some will see 'b') can I control these permissions on my associated grids
Based on your requirement, it looks like you don’t need two views & switch hit.
User A should have a security role A which will filter the data what he can see & cant see.
In security role A modify the Read privilege to BU level - half amber (now it may be full green - Org level)
The same security role A to User B (if they are from different BU) will work as it is. Basically role A has to be there in all BUs individually.
Related
I have created a custom entity in common data services(CDS) that streams in data from a survey.
I'll however need to give access to the data to various people. In my dataset, I have a column called community, which should represent which people have access to what data based on the community they've entered the column.
How exactly can I filter the data, after it has streamed in to ensure I only give access to people of a particular community. And yes every community is exclusive, no two people can be in two different communities.
I want to filter by the community, such that those in community A see only A and not B or C.
There’s no straight one step OOB configuration to achieve this. Because the row level security depends on the column value ie. community field value of each record.
One way is to create owner teams and add the users to right teams, then the custom entity record has to be owned by respective team - owner team of each custom entity record can be filled/assigned automatically based on the community field value on create using plugin/workflow/Flow.
Most important, in security role for that custom entity - read privilege has to be given only for user level. Assign the security role to Teams.
Is any clean way to hide an area from the sitemap, other than reviewing many role privileges one by one and remove privilege completely. I would be ok with amount of work just that there is no one-to-one correlation between the privilege and the menu item and more important, is the fact some of the privileges has many ramifications and I don't want to affect existing functionality. It would be hard to track bugs in this case.
This has to start with the logical grouping of necessary working entities (SubArea) under right Group, and ideally hence the main Area.
Let's say for example - Sales area should have Managers and Reps as Groups then classify the sub-areas for them individually for their needed entities. Then the navigation can be regulated with the help of identifying privileges specific for each persona and the navigation items can be controlled which hide the Group from others. Read more
Or if it is tough to identify such dedicated persona privilege, then create a dummy entity just for sitemap regulation without breaking any existing implementation.
In UCI app world, you can spin a new App for each persona, so silo app with own sitemap and logical groups the way you want.
Lets say
User A belongs to Team X and Team Y
User B belong to Team X
User C belongs to Team X
I want to create a view to display only activities owned by users belonging to Team X and not belonging to both Team X&Y. That result set should only display activities belonging to User B&C.
I created a view but it shows activities of user A as well.
Advance Find
I think you probably want one of these 'equals current user...' options.
Or perhaps simply this - you can enter multiple users.
You also have to keep in mind Security roles and how they impact your views. If you are a SysAdmin, your views will not be filtered at all by ownership - only the criteria you put into the view. If you have a view where "Owner = Team A", then SysAdmin would see all those records where Owner = Team A. If you have a less-permissed user (say, they only have USER LEVEL read on the entity), and the view is "Owner =Team A" - they'd only see records in that view if they belonged to Team A.
It is important to know that User ownership is a mirror of Team ownership. So, User level read actually lets me see ALL records that I own or MY TEAMS own, that satisfy your filter criteria.
Above answer should work - I would use "Equals Current User or User's Teams" but again, depends on exactly what you are trying to do and how everything is setup in CRM
I have users in a team having access to particular fields on lead, opportunity and account entities. I have few users who are in team they just need access to fields on lead and Opportunity entity not on account ?
I thought Ill use field level security on the fields to achieve this, having field level security will have effect other functionality in the system. Any thoughts on how to achieve this ?
Breaking down CRM security levels:
Role level - Entity level (e.g. access to Lead but not marketing list)
Record level - Read/Write/Access (e.g. read lead record but not modify them)
Field level - Field level show/hide (e.g. hide a lead's account field for certain users or team).
In your case, it depends on what defines having access (is it more of a don't need to see or a should not see scenario). If it is just a case of a set of users don't have to deal with certain fields use different CRM forms for different teams, if it is a case of they should not be seeing the data use field level security.
This also would hopefully answer "having field level security will have effect other functionality in the system?" questions, if field level security is implemented, the fields which are restricted read won't show up in the advanced find queries or reports for the users who are not assigned the field level security profiles. Also once you have secured the field, every new user or team needs the field level security profile assigned, else they won't be able to see the field.
The scenario : an Oracle 11g database containing some sensitive user data that could result legal liabilities if disclosed to the wrong party.
The desired effect : only a certain user, connecting from a certain IP, can see the column that contains this sensitive user data
I am not sure that hidden columns or virtual columns are the right ways to do this. It seems that Fine-Grained Access Control could help. I am not sure of what is the best solution. The restriction by IP is probably done at the listener level?
The question :
How can we restrict the visibility of a column so it is only available only to a specific user? All the other users would never see the column, not even when doing a "DESC TABLE_WITH_SENSITIVE_DATA"
Thanks for any tips.
Simplest way to do this is to create a view on the table that does not contain all of the columns. Don't grant select on the table, but only on the view.
The "proper" way to do this is with Fine-Grained Access Control (Virtual Private Database), which can replace the contents of columns with a NULL if certain conditions are not met.
See the example here: http://docs.oracle.com/cd/B28359_01/network.111/b28531/vpd.htm#autoId17
You can probably build this sort of functionality yourself if you're feeling both impoverished and skilled.
Do you the ability to modify roles and create views? Perhaps you could create two separate views and grant access to two different roles for that table. All users that are restricted from seeing the sensitive data would belong to a "restricted" role and the others would have access to the "unrestricted" role. You would need to grant privileges on each view to the appropriate role.
It is important to note that there are restrictions on updating the underlying data associated with a view. As explained here, views that contain set operators, aggregates and GROUP BY DISTINCT and joins and not modifiable.