Microsoft Dynamics CRM (Archived)

Assign Request Not Assigning

(0) Share

Report

Posted on by Community Member

Good day,

Kindly assist,I am writing a plugin that triggers on update of an entity.

This then check a specific attribute on an entity if this attribute is true

It then assigns to the relevant person.

My problem is that it is not assigning at all,but my assign method I have debugged through it it contains all the values and the values are not nulls ,what could be the cause of not to assign ? see code below and assist

try
{
// Create the Request Object and Set the Request Object's Properties

AssignRequest assign = new AssignRequest
{
//User to whome you are assigning the entity to
Assignee = new EntityReference("systemuser", OwningUserID),
////Current record which you are assigning to the user
Target = new EntityReference(TargetEntity.LogicalName, TargetRecordID)

};

// Execute the Request
orgService.Execute(assign);
}
catch (Exception ex)
{
throw new InvalidPluginExecutionException("An error occured while assinging Tier3 User to a DHA Case." +
ex.Message);
}

the following contains information and are not nulls TargetEntity.LogicalName, TargetRecordID,OwningUserID but no assignment is happening.

Help ins this regard will be much appreciated.

Thanks

*This post is locked for comments

I have the same question (0)

All responses (6)

Answers (2)

Suggested answer

Rahul-Waghmare 990 on at

Like (0)

Report

Hi,

Did you get any error?

Please check Security role for the user you are trying to assign the record. To perform this action, the caller must have privileges on the specified entity in the Target property and access rights on the specified record in the Target property.

msdn.microsoft.com/.../microsoft.crm.sdk.messages.assignrequest.aspx

Regards,

Rahul

Was this reply helpful? Yes No
Verified answer

Kumar Viju 1,026 on at

Like (0)

Report

Apart from Rahul Suggestion , Also check if you are performing this below logic.

"This then check a specific attribute on an entity if this attribute is true" - Are you checking any condition before doing the assign logic.

Ex:

If ( CRM. Attribute== true ) --> Make Sure that it goes inside the loop. Since Plugin Execution Context will not check this statement as no update was performed on this attribute.

{

Assign Record To User

}

Because even if the TargetEntity.LogicalName, TargetRecordID,OwningUserID contains values , it will not go into the loop.

Was this reply helpful? Yes No
Conor Gallagher 715 on at

Like (0)

Report

The only issue I can think of is: Are you trying to assign to a user within a different business unit? If so you might need to do this via a workflow (with a custom workflow activity if the code is too complex). I'm not sure why you need to do it this way, but I remember running into a similar problem in the past.

Was this reply helpful? Yes No
Verified answer

Ryan W Anderson on at

Like (0)

Report

The AssignRequest Class is deprecated and the proper way to assign a record is now to use an UpdateRequest that sets the ownerid attribute. See Perform specialized operations using Update for more details.

However, since you are trying to assign the current record, you should be able to accomplish this by registering your plugin in pre-operation and setting the ownerid attribute on the InputParameters["Target] entity.

Was this reply helpful? Yes No
Rahul-Waghmare 990 on at

Like (0)

Report

Please mark the suggested answer so that it will help other community member with correct answer.

Thanks,

Rahul

Was this reply helpful? Yes No
MAJBlackburn 80 on at

Like (0)

Report

We are having an issue where users with the "Assign" privilege global, but Write only their own were unable to assign records they did not own. In CRM 2011, this worked fine, but after migrating, they got the message: "SecLib::AccessCheckEx failed." Effectively the user was trying to Update a record which they did not own, so did not have rights to Write.

So I figured, OK, the Assign Request is deprecated, so the assign button has been updated to do an update instead of an Assign Request. So the immediate solution was to grant the rights needed (since it was never about enforcing security but about enforcing process; they could effectively edit any record by assigning it to themselves first). But then I went back & looked at the network traffic, and the OOTB Assign Dialog *IS* performing an AssignRequest, so their existing permissions SHOULD have been sufficient.

Can you explain what's going on here? I mean, besides you didn't really test the admittedly bizarre permissions grant of "Assign but do not write." I may end up having to write a plugin to enforce the only updates allowed are to the Owner unless the current user is the Owner, which will be annoying.

Was this reply helpful? Yes No