I have an issue related to security role. Below the details.
User A belongs to Security group SG1 and User B belongs to Security group SG2:
Both the roles have below privileges(same) on a custom entity, but the Business Unit is different for both Security Group.
create: user level, Read: Business Unit , Write: user level, Append:Business Unit, Append To:Business Unit, Assign:User level , Share:Business Unit
When user A in SG1 trying to assign his record to a user B in SG2, I am getting Access Denied error.
When the owner changes user A will loose access and get the error. But here, even if I am getting the Access Denied error the owner is not changing in entity, when I am reloading the record the owner is still User A(I think the save is not happening).
Error Log:
Exception Message: Principal with id ef346db1-c98f-ec11-b400-000d3ac25c59 does not have ReadAccess right(s) for record with id ef346db1-c98f-ec11-b400-000d3ac25c59 of entity my_product. Details: {"CallerPrincipal":{"PrincipalId":"038cfa23-c74e-ec11-8c62-6045bd8f574d","Type":8,"IsUserPrincipal":true},"OwnerPrincipal":{"PrincipalId":"87242295-6ef2-ea11-a815-000d3a23ca40","Type":8,"IsUserPrincipal":true},"ObjectId":"ef348db1-c98f-ec11-b400-000d3ac25c59","ObjectTypeCode":10501,"EntityName":"my_product","ObjectBusinessUnitId":"a4854691-c946-ec11-8c62-000d3a472098","RightsToCheck":"ReadAccess","RoleAccessRights":"None","PoaAccessRights":"None","HsmAccessRights":"None","GrantedAccessRights":"None","Messages":["PrincipalHasOwnerPrincipalWithAtLeastBasicPrivilegeDepth = False","EntityUserGroupRights = None","MinimumPrivilegeDepthRequired = Local","SecLib::AccessCheckEx2 failed. Owner Data: roleCount=1, privilegeCount=822, accessMode=0; Principal Data: roleCount=1, privilegeCount=822, accessMode=0"],"EntityOwnershipTypeMask":1,"CallerInfo":{"IsSystemUser":false,"IsSupportUser":false,"IsAdministrator":false,"IsCustomizer":false,"IsDisabled":false,"IsIntegrationUser":false,"Teams":null,"Roles":null},"ReadOnlyState":"UserAndOrgFullAccess","IsHsmEnabled":false,"HsmInfo":null,"AccessOrigin":null}
ErrorCode: -2147187962
HexErrorCode: 0x80048306
ErrorDetails:
0: my_product
1: ef346db1-c98f-ec11-b400-000d3ac25c59
2: 10501
3: ReadAccess
4: ef346db1-c98f-ec11-b400-000d3ac25c59
5: 8
ApiExceptionSourceKey: Step/Microsoft.Crm.Extensibility.ImageRetrievalStep
ApiStepKey: 84b9d1cb-3e30-11db-b951-000cf1fe02ff
ApiDepthKey: 1
ApiActivityIdKey: c6338644-38d6-422f-9ccc-2d1284ef241d
ApiPluginSolutionNameKey: System
ApiStepSolutionNameKey: System
ApiExceptionCategory: ClientError
ApiExceptionMessageName: unManagedIdsAccessDenied
ApiExceptionHttpStatusCode: 403
This is expected behavior.
Issue 1 - Assign:User level
This limits the assign privilege to another BU user, Change it to BU level and it should work.
Issue 2 (eventually you will face) - Read: Business Unit
As the users (SG) belongs to different BUs and Role has only BU level read, the moment a record is assigned to another cross BU user - the original owner lose access and read privilege for that particular record. Like you mentioned the error will popup.
Related
In CloudCode, is there any utility function which I can determine that the current user belongs to a certain role?
Assume the following role hierarchy Admin->Manager->User
If I added user1 to the Admin role, this means if in cloud code if I query all the roles this user belongs to, then I will get immediate list of roles not hierarchy. I am wondering if there is a utility function that helps with this issue?
In Microsoft Dynamics CRM 365 the security roles have an "Append" and "Append To" rights. What does "Append" and "Append To" mean and what is the difference between them?
I googled for the answer, but cannot find a definitive one.
Append and Append To are two privileges that most user are not very clear about regarding their functionality. In this article we try to explain the difference between “Append” and “Append To” Privileges and how it affects the user access.
Append and Append To basically deal with the entities that are parties to a 1:N relationship or N:1 relationship.
Append: When an entity has the lookup of another entity on its form. It is important that the user has the “Append” privilege on this entity so that it can set the values for the lookups on this entity. For eg: Contact has the lookup of Account on its form so here the user needs to have the “Append” privilege to be able to set the parent account.
Append To: When an entity is available as a lookup on another entity form. It is important that the user has the “Append to” privilege on the entity that is referred to in the lookup so that it can set the values for the lookups of this entity on any other form. For eg: Account has the lookup of primary contact. So here the user needs to have the “Append To” privilege to be able to set the Primary Contact for the Account.
Lets us take an example of Contact entity.
We have modified the Order Role and removed the “append” privilege to the Contact entity.
When a user with this role logs in, they would find the Parent Account lookup disabled.
This is because the user does not have the “Append” privilege to the contact entity. So all the lookups on the contact form are Disabled.
Now we have modified the Order Role and provided the “Append” privilege for the contact entity and removed the “Append To” privilege from the contact entity.
The Primary Contact on Account is disabled.
It means the lookup of contact entity will be disabled on all the entities if the “append to” privilege to contact is removed.
Reference for the blog: https://community.dynamics.com/crm/b/crminogic/archive/2010/05/03/append-v-47-s-append-to
You probably won't find anything because there is no concept called "Assign" and "Assign To" rights.
We have "Assign", "Append" and "Append To" privileges.
Assignment is nothing but changing the owner lookup value of the entity record from user A (or Team X) to user B (or Team Y).
Excerpt of better definition for Append and AppendTo:
One way of thinking conceptually about Append and Append To is to think of ‘Append Me‘ and ‘Append To Me‘.
In order to successfully append record A to record B, the security privileges must be set to allow both sides of the agreement. Consider the following metaphor, Append ‘knocks on the door’ of another entity and Append To is needed to ‘open the door’ to that entity. For example, if you want to qualify an Account and begin working the opportunity as set in your business process flow, you must have to rights to append the Account (record A) and the rights to append to the opportunity (record B).
Read more
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.
We're building our API and looking for an organized way to grant users access based on what role and permission they have.
From the starting point, we have 3 roles
Admin: can get and edit everything in his organization
Team Admin: can get and edit only his team info and users' info
User: can get any edit his own information
Entity
Team
User
For Security Filters:
We're using JAX-RS with Security Roles and #RoleAllowed to filter access to resources
Id-based filter by if / then / else function. Example with a team admin access to a user.
function isAllowAccess(teamAdminId, userId) {
allowedUserIdsList = queryfor(teamAdminId);
if (userId in allowedUserIdsList) then ... else BAD_REQUEST
}
This code is growing with the increase complexity of multiple roles and many entities. So my questions:
What will be the best way to have an organized id-based filter, is there reputable library for this?
Should we maintain a separate table containing accessible ids of each
entity for each team_admin_id? Then every row updated or inserted will trigger the update of this table.
Is there a formal or widely acceptable method to reduce database
call overhead in each call just to check if the team_admin is
allowed to access a particular user?
I wrote a script (VBScript) to create/update CRM users based on an external MySQL database. Everything works great except for automatically setting the user's manager. In the MySQL database, each user has a unique ID and a reports_to field with the ID of his manager if any.
In the CRM, a custom field in the SystemUser table contains the unique user ID from the external table. This way, by looking at the external reports_to field I can link a CRM User to another. The worst part is that it actually works for some users, until it reaches one that brings an error: "The user is not in parent user's business hierarchy." Can someone explain me what this error is about ? I could not find any details or similar cases on the Internet.
I can manually set the Manager for this user in the CRM and it does not give me any error.
Here is my code:
Dim ManagerUser As New SystemUser
ManagerUser = GetUser("tld_id", clrint(User._reports_to), _serviceProxy)
If Not IsNothing(ManagerUser) Then
Dim ManagerId As Guid = ManagerUser.Id
Dim Manager = New SetParentSystemUserRequest
Manager.ParentId = ManagerId
Manager.UserId = _UserId
Manager.KeepChildUsers = True
_serviceProxy.Execute(Manager)
End If
Ok I found what it meant.
Some Business Units in the CRM are Parents from others. I was working with a DEV MySQL table (still test phase) that had unclean data. It resulted in some users having the wrong BU set.
Error was triggered when the manager belonged to a BU child from the user's one.