Error when running a FUD comparison with Windows Authentication

Error: Exception of type Fusion.FusionSecurityException was thrown.
Version: ITSM 506 P3
Error Details:
---------- EXCEPTION >>
FusionSecurityExceptionMessage: Exception of type Fusion.FusionSecurityException was thrown.
Source: CompareBroker.CheckSecurity
TargetSite: Void CheckSecurity(Fusion.Api.IFusionApi, System.String, System.String)
StackTrace:
at Orion.DefinitionEditor.Broker.CompareBroker.CheckSecurity(IFusionApi iApiTarget, String strRightToCheck, String strErrorMessageName)

at Orion.DefinitionEditor.Broker.CompareBroker.DoCompare(IFusionApi& iApiTarget, FusionPrincipal& fpForTargetAPI, String strTragetDatabase, PlaceHolder[] arPHsToCheck, Boolean bDeepCompare)

at Orion.DefinitionEditor.UI.ExportCreateUpgradeCompare.DoCompare()
at Orion.DefinitionEditor.UI.ExportCreateUpgradeCompare.button1_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Conditions:
When running a comparison between 2 ITSM databases selecting the "Compare" button generates the above error.

Issue:
When the system validates against the target database (ie. the one selected during the FUD wizard not the one you originally logged in with) it uses Windows Authentication to connect to the database. If the user doesn't have sufficient rights to do the export the error is thrown and no Login is provided. This is the case even if the CTRL login option is used for the initial log in.

Work Around:
Increase the user with windows authentication to Administration rights.

Calling Alerts (popups) in ITSM Jscript Functions

The following is a section of Jscript to call the Message Box object from System.Windows.Forms within a script type ITSM Function. It can be called using Alert(“text in here”); or Alert(+variable name);

//The following function presents a message box to the user when //called using Alert(“text in here”); or Alert(+variable name);



function Alert
(
Message : System.String
)

{
var asm : System.Reflection.Assembly
var typ_win : System.Type



//Get the main form object from the remote type

try

{
//Get a pointer to the System.Windows.Forms assembly

asm = System.Reflection.Assembly.LoadWithPartialName("System.Windows.Forms");

//Get the MessageBox type from System.Windows.Forms

typ_win = asm.GetType("System.Windows.Forms.MessageBox");

//Execute the Show method of the Message box object

var argMSG : System.Object[]
argMSG = new System.Object[1] ;
argMSG[0] = Message;
typ_win.InvokeMember

(
"Show", //The member name
System.Reflection.BindingFlags.InvokeMethod, //Binding Flags
null, //Binder
null, //Object
argMSG //Arguments
);

}
catch(exc : System.Exception){}
}

Issue in Self Service (ITSM all versions to 5.06 patch 3)

The issue occurs if the users are able to update incidents through the SS interface and are able to access all incidents that are created for them. Here is the scenario that causes the issue.

Scenario:
1. Service Desk Analyst JohnA logs into ITSM Client and creates a new incident for (on behalf of) BobS (a user with access to self service) and saves it in the system. (for example calls the Helpdesk with an issue)
2. Self Service User BobS logs into self service (at some later point) sees the incident created in Step 1 and selects the incident.
3. With the incident open in Self service BobS adds some more detail to the incident and Saves the incident.
4. BobS goes back to view history of Self Service and the incident (that was updated in step 3) is missing from the list.
5. JohnA logs back into ITSM Client and looks up the issue created in step 1 and the customer information is no longer for BobS but is now JohnA.
Issue:
The issue is whenever a user in self service updates an incident where they are the customer (and hence in their SS view) and it was created by another user the customer details revert to the user who created it.

Cause:
The issue is caused by a function that is on the ProfileLink field in the WebSelfService Perspective. The function is "Set Incident Requestor" and is set as a "Before Save" value on the ProfileLink Field. The offending section of code is below (lines 14-20):

var objReturn : Object;
var strCreatedByRecId : String;
strCreatedByRecId = currentBusinessObject.GetField("CreatedByRecId").NativeValue;

currentBusinessObject.GetField("ProfileLink+LinkID").SetValue(new Fusion.FusionValue(strCreatedByRecId));
currentBusinessObject.GetField("ProfileLink+LinkCategory").SetValue(new Fusion.FusionValue("Profile.Employee"));

This section of code causes the ProfileLink values to be reset to the CreatedByRecId ever time a Self Service user updates an incident. In the OOB system this isn't too much of an issue as the SelfService users only see incidents created in self service. In most implementations though this is expanded so that all incidents created for that user are visible in self service.

Resolution:
The issue can be resolved by adding a new field "ProfileRecID" to the incident, having it autofilled from the ProfileLink field with the value of RecID in any non Self Service perspective. Setting a Default Of "Current User Record ID" in the Self Service Perspective (the same as CreatedByRecId is in the OOB system). Then updating the Function to use this field instead of the CreatedByRecID.

Conclusion:
I've tested this and have discovered it now in the oob system and in a few other implementations. It's not an obvious issue but does cause incidents to get lost when it does occur.