Does anyone know of any way to update the ‘ticketnumber’ field on an ‘incident’ entity after the incident has already been created?
The field is locked down on the front end and have tried via the API using C# code however this fails to write also?
It might not be what you need to do, but you can write a pre-operation plugin working on the create message of the incident to override the ticket number that has been assigned set as the default.
We do this to enable custom ticket numbers to be used, but have never had the need to update them after this point
Related
I am writing a Post PLugin changing the owner. When the owner has a substitution manager, the owner is changed to the substitution manager. I tried a service.Update and an AssignRequest, but these throw an exception.
When I post the request my entity cannot update (and then throws "The request channel time out while waiting for reply after 10:00:00"). But like I see there is no recursion, because when I logged it I have only one repetition of log and it has stopped before or on line with update.
var assignedIncident = new AssignRequest
{
Assignee = substManagerRef, //get it throw another method, alreay checked in test it`s correct
Target = new EntityReference ("incident", incedentId)
};
service.Execute(assignedIncident);
I tried to write target in another way
Target = postEntityImage.ToEntityReference()
I tried to write simple update but the problem is the same.
Entity incident = new Entity("incident" , incidentId);
incident["ownerid"] = substManagerRef:
service.Update(incident);
Can somebody help me with that? Or maybe show the way to solve it)
The plugin is triggering itself and gets in a loop. The system only allows a maximum of 8 calls deep within plugins and that is the reason it throws an error and rolls back the transaction.
To solve this issue redesign your plugin in the following way:
Register your plugin on the Update message of your entity in the PreValidation stage.
In the plugin pick up the Target property from the InputParameters collection.
This is an Entity type. Modify or set the ownerid attribute on this Entity object.
That is all. You do not need to do an update, your modification is now passed into the plugin pipeline.
Note: for EntityReference attributes this technique only works when your plugin is registered in the PreValidation stage. For other regular attributes it also works in the PreOperation stage.
I need to filter users with the onPremisesExtensionAttributes [extensionAttribute6] is there a graph API call for it?
As #Tinywa suggested in the comment:
onPremisesExtensionAttributes contains extensionAttributes 1-15 for
the user. Note that the individual extension attributes are neither
selectable nor filterable.
You can get all the results first and use your own code logic to filter them.
Or you can consider using extensionProperty as a workaround. Create the extensionProperty and assign value for the users, and then query users with filtering with this extensionProperty. For detailed steps to create extensionProperty and assign value for users, you can refer to this answer.
It looks like they've updated the BETA Graph API so that extension attributes (onPremisesExtensionAttributes) are now filterable.
Try the below in Graph Explorer. You'll need to change the extensionAttribute1 eq 'Employee' part to a query that will actually work in your active directory environment.
https://graph.microsoft.com/beta/users?$count=true&$filter=onPremisesExtensionAttributes/extensionAttribute1 eq 'Employee'&$orderBy=displayName&$select=displayName,mail,onPremisesExtensionAttributes
Please note that this is the BETA Graph API so I guess that means Microsoft hasn't finalized it, so it might change or never get fully released.
EDIT: I also just learned that if you're using this filter via the Graph API, you must add the following header or you'll an error:
client.DefaultRequestHeaders.Add("ConsistencyLevel", "eventual");
The Graph Explorer has this header by default, I guess.
Here's where I found this answer: Get Extended Properties on User using Microsoft Graph
Here's the error I was getting:
Property 'extensionAttribute1' does not exist as a declared property or extension property.
We call the microsoft exchange to set the extended property which in our case is an unique guid
microsoft.exchange.webservices.data.core.exception.service.remote.ServiceResponseException: An internal server error occurred. The operation failed., Invalid named property
Its been working great until now when some of our users are facing the above issue ....
val uId = getUniqueId();
val emailExtendedPropDef = new ExtendedPropertyDefinition(uId,"uniqueId", MapiPropertyType.String)
try {
email.setExtendedProperty(emailExtendedPropDef, uId.toString)
email.sendAndSaveCopy()
} catch {
case e: Exception =>
error(s"Exception in setting extended property for user $from", e)
throw e
}
trying to find the root cause of the issue, we are also thinking it might be related to throttling on Microsoft exchange for extended properties (Not sure how to prove if it's indeed throttling) any help to point us in the right direction will be of great help
Our use case is to able to retrieve the email when customer want's to reply back we want to retrieve that particular email to be included in users reply....currently we are using the uid to achieve that ....
we have been using the code as per the documentation here
https://learn.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2010/dd633654(v%3Dexchg.80)
and also the documentation here
https://github.com/OfficeDev/ews-java-api/wiki/Getting-Started-Guide#extended-properties
Update : As per the comments we do understand that we have to treat extendedProperty as a column definition and update the same column ...but we couldn't figure out how to achieve this as...Any code samples to point us in the right direction will be of great help
Latest Update : We have deleted some of the extendedPropertyDefinition's but still facing the same invalid property could some one please point us in the right direction
Is it safe to say that getUniqueId returns a different guid on each call? If so, then that is the problem. Think of the Guid for an extended prop as a namespace. The exchange store limits the number of custom extended props to something like 32k per mailbox. So you are likely hitting that limit. But aside from that, the main reason for creating an extended property is so that you can refer to it later. But if you are basically discarding the namespace each time, you are leaving orphaned props on items. Without understanding your particular scenario, I can only say that the Guid should be thought of truly as a namespace. Choose one for your app/company/scenario and hard code it. They create all the named props you want within that namespace. For instance, "MyProp/String" in Guid namespace 1 is a different property than "MyProp/String" in Guid namespace 2.
I am trying to develop a Rails application for QuickBase for which there is no adapter. I checked online for the QuickBase adapter but it is not working as it is for a very old version of rails and the author told me that he no longer supports it.
I want to be able to use the Active Record and the associated concepts of a typical rails application, but intervene and modify how the create, update and show actions work. I have created the application to create a new record successfully. However, when I want to be able to edit the record, I have first modified the edit action to go to my own database and get the data into an active record object.
To create an empty Active Record I said $user = User.new
Then I populated all the attributes with the data from my custom database. But the form still shows the Create User button, instead of Update User button. Apparently, I guess this is because the persist? method is returning false as this is a "new" object. But I know this is not a new one. So how do I influence the #user object to think it is a persistent one?
Alternatively, is there a way I can create the blank #user object without the new function?
I have checked all over the place, but couldn't find any clue on how to accomplish this. Thank you so much for your help.
You can try calling #user.disconnect! after your call #user = User.new, which will keep ActiveRecord from trying to write to the database, but I'm not sure that will solve your problem.
The larger problem is that you're trying to fit a square peg into a round hole here. The entire point of ActiveRecord is to abstract the connection to a database. So without a database, what's the point?
I think your best solution would be to write your own QB adapter. It may not be as difficult as you think, since you already seem to know how to read/write to the database.
You can read more about how to do that here: http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html
I have a problem, which I'm really trying to figure out how I could best solve this. I have read various posts regarding this error and seems you can avoid this by using JavaScript by using:
Xrm.Page.getAttribute("name").setSubmitMode("always");
which doesn't work for me or inside the plugin. Now to my problem, I have an update plugin firing on my incident form, which updates some fields. However when I try to resolve the case or cancel it I get the error from my update plugin "The object cannot be updated because it is read-only" I have tried the following and would appreciate if somone could advice me what I'm doing wrong. My code for a plugin I'm registering as SetState on pre-operation against the incident form:
SetStateRequest setState = new SetStateRequest();
setState.EntityMoniker = new EntityReference();
setState.EntityMoniker.Id = incidentId; //Id which needs to be resolved/canceld
setState.EntityMoniker.Name = "statecode";
setState.EntityMoniker.LogicalName = "incident";
setState.State = new OptionSetValue();
setState.Status = new OptionSetValue();
SetStateResponse setStateResponse = (SetStateResponse)service.Execute(setState); }
On the state and status I'm quite confused to what value I have to set it to. I'm just getting an error when my incident is on Active and I'm trying to resolve and cancel the case. I would appreciate if someone could help me out here. Thanks in advance.
I think there are a few areas of confusion in your post...
Xrm.Page.getAttribute("name").setSubmitMode("always");
This is clientside code and will never have any bearing on the behaviour of your (serverside) plugin. It merely forces an attribute on the form to be submitted whether it has changed or not, during a save. If the record is in a read-only state, it will not change that fact.
I'm not at all clear what you are trying to acheive in your code. You mention that an update plugin is failing; you have posted code which would attempt to set the state of the incident to something (as #glosrob suggests, you are not providing any values in the OptionSetValue objects for State and Status so as you might already know, the code you have posted is invalid); you then state that you have registered your plugin on the SetState request. This means that it would fire if the user tries to set the state of the incident. Given that your code is itself trying to set the status of the incident, I'm not sure that it makes sense...
It sounds like what you want to do is, on update of an incident, set certain values. If the incident is in a read-only state, make it readable first, and then update the values. Do you then need to restore the state of the entity to it's former state? It sounds awkward and might perhaps suggest that there is a better way to meet your core requirement.
Maybe start with what you are trying to achieve and we can work from there :)
You should remove
setState.EntityMoniker.Name = "statecode";
from your code. This field Name has other purpose.
Also, you should add
setState.State.Value = 1;
setState.Status.Value = -1;