ALM Workflow: Always Trigger Bug_New when “New Defect” is Clicked

One “feature” in HP’s Application Lifecycle  Management (ALM) and Quality Center relating to the Defects module is the ability to add multiple defects without ever closing the “New Defect” window, and to resume populating a new defect after the “Close” button is clicked. When the user clicks the “Close” button and then “New Defect”, the field values are cached. This can be a great time saver; however, it is not without its unintended consequences. This means that the Bug_New event is not triggered when clicking the “New Defect” button, which can have adverse effects.

Imagine this scenario:

  1. From within the Defects module, click the  ”New Defect” button.
  2. Begin populating a new defect record.
  3. You notice that something odd has happened – a required and read only field that should automatically be populated is empty. You cannot insert a new defect. You then click the “Close” button assuming you will have a clean defect window when you click “New Defect” again. Note:  You also reported this bug to your workflow guru (or attempted to debug this yourself), but he/she cannot determine the cause (or reproduce the issue) as it seems sporadic.
  4. You now click the “New Defect” button to start a new defect. The defect record is in the same state as when the “Close” button was clicked. You are now stuck – you cannot submit a defect record, unless you log out or enter the Customization area (from within Tools), because the field values are cached at this point and the state of the required field is still read-only.

Adding debug code (MsgBox) in Bug_New illustrates that the event is not triggered after the “Close” button in the “New Defect” window is clicked (and then the “New Defect” button is clicked). Bug_New is not triggered again until a defect record is saved.

To work around this “feature” we have to add code to the DialogBox subroutine that executes code every time the “New Defect” button is clicked. Essentially, Bug_New will execute every time you expect it to, bypassing the built-in “feature.” In Bug_New and DialogBox you will need to call an initialization function (CUSTOM_BUG_Init) that clears all of the fields on the record and sets the location, visibility and read only properties of fields. CUSTOM_BUG_Init must still be called from within Bug_New because the DialogBox event is not triggered after clicking the “Submit” button. A global variable will need to be used that tracks when the CUSTOM_BUG_Init function has been executed (so that it is not executed twice when clicking the “New Defect” button). Below is that code in action, tested in ALM (Quality Center) 11 (Patch level 0 through SP3).

Of course, the code in DialogBox event can be extended to handle other modules.

Place the code immediately below in the “Common script” area:

' ************************** GLOBAL VARIABLES ************************
'
Dim gv_BugInitCalledFromDialogBox
gv_BugInitCalledFromDialogBox = False
' ********************************************************************

Sub DialogBox(DialogBoxName, IsOpen)
  'Use ActiveModule and ActiveDialogName to get
  'the current context.
  On Error Resume Next
 
  If DialogBoxName = "New Bug" And IsOpen Then
    ' The "New Defects" button is clicked...

    ' Set a global variable so that the init function is not
    ' executed twice when clicking the "New Defect" button.
    gv_BugInitCalledFromDialogBox = True
    CUSTOM_BUG_Init
 
  ElseIf DialogBoxName = "Bug Details" And IsOpen Then
    ' An existing Defects record is opened; does not fire when
    ' selecting a defect in the defects grid
  End If
 
  On Error GoTo 0
End Sub

Place the code immediately below in the “Defects module script” area:

Sub CUSTOM_BUG_Init
  On Error Resume Next
 
  ' Add code that occurs every time a "New Defect" window is opened
  If Bug_Fields.Field("BG_BUG_ID").IsNull Then ' A new Defect
    CUSTOM_BUG_ClearRecord
  Else  ' An existing record
    ' Code that executes when an existing record is opened
  End If
 
  ' Add code to set the position, visibility, and read only
  ' attributes of the fields.

  ' Reset the global variable so Bug_New can execute after the
  ' "Submit" button is clicked.
  gv_BugInitCalledFromDialogBox = False
 
  On Error GoTo 0
End Sub
 
Sub CUSTOM_BUG_ClearRecord
  On Error Resume Next
 
  ' Clear all fields on the form.
  For i=0 To Bug_Fields.Count
    Bug_Fields.FieldById(i).Value = Null
  Next
 
  On Error GoTo 0
End Sub
 
Sub Bug_New
  On Error Resume Next
 
  ' If the Init function has not been called from the DialogBox,
  ' run it. This will execute after the "Submit" button is clicked.
  If gv_BugInitCalledFromDialogBox = False Then
    CUSTOM_BUG_Init
  End If
 
  On Error GoTo 0
End Sub
 
Sub Bug_MoveTo
  On Error Resume Next
 
  CUSTOM_BUG_Init
 
  On Error GoTo 0
End Sub

Is your standard workflow complex enough that this method will need to be utilized in your next workflow customization project, or do you plan to implement this code in your existing workflow? Have you already recognized this “feature” as a drawback in your existing workflow? Have you used other methods to accomplish the same task? Let us know by leaving a comment below.

What's Next?

Did you enjoy this article? Help spread the word by sharing:

Join the Northway Navigator Club today and get access to restricted content including our best tips and tricks. Membership is free! You will also receive free email updates by registering.

Engage in the conversation and leave a comment:

Brian MacKenzie

About Brian MacKenzie (24 articles)




Brian has over 14 years of experience working in IT, ranging from Software Quality Assurance, Software Development, Business Management to Systems Administration, in a wide range of technologies, languages, databases, systems and software. He has experience in both software quality assurance and software development roles. Brian specializes in HP LoadRunner, HP UFT (QuickTest Pro and Service Test), Mobile Testing and Automation, HP ALM and HP Service Virtualization, as well as delivering certified instructor training in HP UFT and mentoring in Service Test and Service Virtualization.



  • Nima

    Hello,

    Was wondering if anyone can help I am trying to write afunction in vbscript editor of QC to:
    send me a email when a new defect (bug) has been raised in defect module of QC, can anyone help?
    Many thanks

    N

    • http://northwaysolutions.com/ Brian MacKenzie

      There are a couple of says to do this. One is to setup logic inside “Bug_AfterPost”. For additional information about the “Mail” method for “BugFactory.Item”, reference the ALM/QC OTA documentation. Here is some sample code, which has not been tested. Hope this helps.

      Sub Bug_AfterPost

      ‘ Sending email is status based. You must have a status
      ‘ or field set that indicated the first time a defect is submitted.
      If Bug_Fields.Field(“BG_STATUS”).Value = “New” Then

      ‘ Setup email addresses and email content
      Dim strTo, strCC, strSubject, strComment
      strTo = “to@email.com”
      strCC = “cc@email.com”
      strSubject = “New Defect Notification” & _
      ” for project ” & TDConnection.ProjectName & _
      ” in domain ” & TDConnection.DomainName
      strComment = “The user ” & User.FullName & _
      ” added a new defect.”

      ‘ Send email
      Dim objBugFactory, objBug
      Set objBugFactory = TDConnection.BugFactory
      Set objBug = objBugFactory.Item(Bug_Fields(“BG_BUG_ID”).Value)
      objBug.Mail strTo, strCc, 2, strSubject, strComment
      Set objBug = Nothing
      Set objBugFactory = Nothing

      End If

      End Sub

      • David

        Hi.
        This is all really useful, thanks. I currently have a batch script which I run outside QC so that whenever I create a new defect I run the batch file, it prompts for the defect number, and then it tells another tool of the existence of this new defect. I’d like to effectively copy the contents of that batch file into Bug_AfterPost so it’s automated within QC.
        But I’m new to QC and I’ve fallen at the first hurdle: How/where do I actually enter code like the Bug_AfterPost sub above? Is it in the QC GUI?
        Thanks very much.
        David

        • Brian MacKenzie

          David – this code is entered in the Workflow Script Editor (Project Customization).

          • ravi

            Hello,

            When we create a new defect, detected By and Detected on Date fields are Auto filled. But this code even clears these fields. Some times, these fields will be non editable during creation of new defect. In that case, when this code is called, the field values are cleared and we cannot enter anything as they are non-editable. This code doesn’t work then.

            Regards,
            Ravi

          • Brian MacKenzie

            Ravi,

            “CUSTOM_BUG_ClearRecord” clears all field values. You will need to add additional code to handle the “Detected By” and “Detected On” fields to retain those values. This is absolutely achievable using the code in this article as a starting template.

            Thanks for the comment!

          • Ravi

            Hello Brian,

            Yes, we need to add additional code inorder to handle those fields. I will try to do that.

            Regards,
            Ravi

  • Ron DeMott

    Just so you know, there is a red X in the upper left corner of the New Defect window. This will allow the user to clear all fields (including field values from a previously cancelled New Defect). So, I don’t think that you’re “stuck”, as you mentioned in Step #4.

    • Brian MacKenzie

      Ron,

      After reviewing the article, I realize that step #4 was not entirely clear in stating the problem (i.e., why you are “stuck”). I have further clarified this in the article.

      The problem is not that you cannot close the dialog window – you can. The problem that the field values are cached at this point. In this scenario, that means you cannot add new defects until you log out of ALM (thus clearing the cache) because the workflow does not take into account field caching.

      The overall objective of the article is to point out that the field value caching feature can have unintended side effects, and that “Bug_New” is not always called (as one would expect).

      Thanks for the feedback and I hope this helps clarify the scenario.