What if you think you can update a record, and there are all the indications that you can, yet you try to change something and it just does not work?
In the example below(which I’ve originally discovered in 8.2.2, though the screenshots below are from 8.2.1), my test user seems to have “write” permissions, the form is not read-only in Dynamics, so I can modify field values on the form:
And yet, I’m getting an error message when trying to save the changes:
<Message>SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: c1d0e243-1e18-e811-9401-00155d00c101, OwnerId: 5c19475b-16f4-e711-93fe-00155d00c101, OwnerIdType: 8 and CallingUser: 5c19475b-16f4-e711-93fe-00155d00c101. ObjectTypeCode: 10018, objectBusinessUnitId: 63746438-10f4-e711-93fe-00155d00c101, AccessRights: WriteAccess </Message>
So what happened?
“Security Test” is a new entity I just created
There is a security role that’s setting access to that entity like this:
Now here is the catch: that security role is not assigned to the user – instead, it’s assigned to the team, and my use is a member of that team.
And that team has a role:
You would think my test user would have permissions to update the record. AccessChecker plugin in XrmToolBox seems to think so. Dynamics client side itself seems to think so.. But, apparently, something fishy is happening on the server side – it has its own opinion about who can actually update that record.
Interestingly, it’s all working fine if the record is assigned to the team instead. As a member of the team, my test user can happily update such records. I can even assign that record from the team to myself under that user account (because yes, the role has that permission). But, once the record has been assigned to me, it’s all over – there is nothing I can do with that record anymore.
BTW, the workaround for this is relatively simple – I just need to assign the same role directly to my test user.
This isn’t a bug, but rather how security is treated in the system when it comes to team membership. The thing to remember here is that being a member of a team doesn’t mean the user has the roles granted to the team. It means the user can see and do what the team can do as the team which is why the change operation works when you change the record owner to the team. This is the fundamental basis of the ownership security model.
I would argue it is a bug:) What exactly is the bug in this situation is a different question, though. Look at what XrmToolBox thinks about user privileges, and I’m sure it’s using SDK to assess them. The same is happening on them form.. So it’s either a bug in the SDK, or it’s a bug in the security model. And keep in mind I can change that role to give write access on the BU level and it all starts to work. Why? In my mind, a bug is not necessarily when something is absolutely incorrect.. inconsistency is a bug, too.
It’s not a bug. Write permissions are set to only records belonging to the team yet the record is owned by the user.
Now it is arguable that the logic should work the other way and that the permissions as set should allow the user to write to records that are owned by either him/herself or the team but that opens up an issue in a scenario where you really don’t want users updating the records they own.
So the rules as set out are designed to maximise granularity. If you want the user to be able to update records owned by both himself and the team you need to give both him and the team the security role.
Ben, I realize that we’ve all seen the same issue with “create” popping up every now and then. There is a “write” issue, too. But I never called server-side logic a bug in my post – have a look at it again. However, if the security is expected to work this way, then there is a bug on the client side – normally, when I don’t have update permissions, I am supposed to see readonly form. In this example, it’s an updatable form, and I’m only getting an error message once I hit “save” button. There seem to be a bug in the SDK, too, since I am pretty sure access checker plugin in XrmToolBox is using the SDK (What else can it possibly use??) So just make all part of the system work the same way.. otherwise, you may not call it a bug, but it is.