Obtaining Current Relationship on a Work Item form (custom.js)

Adam_Dzyacky

I've made a Task based version of @john_doyle's "Send Email" but it's unclear to me what would be the best way to obtain the current Affected User on a Work Item (I'm sure it's the API but it isn't entirely clear how I can go about this). Which is to say, how does one obtain currently defined items, relationships, and their properties on the form (like the native Send Email)?

• Using the View Model I can obtain the AU, but if i change the AU, don't save and re-use the link as expected it builds an email to the original AU instead of the one currently defined on the form/view model

Tom_Hendricks

I submitted a bug ticket with Cireson a few weeks ago about the AU not changing in the viewModel when the field is changed (other than the "name" and "Id" properties, which do change--the rest always refer to the original object, which can create a confusing mix!).  This is truly a bug if you are using the ExtraProps to show extended properties like "VIP", for example.

Having said all that, the best way (IMHO) is off the table because you cannot trust the viewModel unless the ticket is saved and otherwise unmodified since the save.  However, since the Name and Id properties of the AU do update correctly, you can take a hybrid approach.

Grab the email address using the api/V3/User/GetUserRelatedInfoByUserId?userId={userId} API call, where {userId} is viewModel.RequestedWorkItem.Id and then grab the email (or possibly UPN, depending on your AD setup) property from there.

There is an obvious inefficiency to this compared to being able to ask the viewModel directly, but it should work.

EDIT: I'll leave this here, but after writing it I noticed that this is precisely what @john_doyle's code is doing.  I still maintain that the email should simply update correctly as the AU is changed so that it can be grabbed directly from the viewModel, however.

Tom_Hendricks

I submitted a bug ticket with Cireson a few weeks ago about the AU not changing in the viewModel when the field is changed (other than the "name" and "Id" properties, which do change--the rest always refer to the original object, which can create a confusing mix!).  This is truly a bug if you are using the ExtraProps to show extended properties like "VIP", for example.

Having said all that, the best way (IMHO) is off the table because you cannot trust the viewModel unless the ticket is saved and otherwise unmodified since the save.  However, since the Name and Id properties of the AU do update correctly, you can take a hybrid approach.

Grab the email address using the api/V3/User/GetUserRelatedInfoByUserId?userId={userId} API call, where {userId} is viewModel.RequestedWorkItem.Id and then grab the email (or possibly UPN, depending on your AD setup) property from there.

There is an obvious inefficiency to this compared to being able to ask the viewModel directly, but it should work.

EDIT: I'll leave this here, but after writing it I noticed that this is precisely what @john_doyle's code is doing.  I still maintain that the email should simply update correctly as the AU is changed so that it can be grabbed directly from the viewModel, however.