Root > How to... > ...change send workflow?

...change send workflow?

Previous pageReturn to chapter overviewNext page   

Sometimes EurekaLog does not have an option to implement a behavior that you want. If this is the case - you can alter behavior of build-in send method. Default behavior (for bug trackers) is described in this article.

 

All EurekaLog send methods are implemented in WinAPI, wrapped inside classes with lots of virtual and helper functions. Base send class is TELUniversalSender from ESend unit. All send methods are child classes from this class. For example, Mantis send method is implemented as TELTrackerMantisSender class from ESendAPIMantis unit. If you want to alter any aspect of default send method - you need to sub-class it and override desired virtual methods. You can also call inherited helper methods to simplify developing.

 

First, you need to subclass the desired send method class:

 

uses
  ESendAPIMantis;
 
type
  TELTrackerMantisSender = class(ESendAPIMantis.TELTrackerMantisSender)
  // ...

 

The example above uses Mantis as example. If you want to customize a different send method - you will need to replace unit name and class name.

 

You must use the same class name as original class. You'll have to append unit name to class ident to avoid compiler confusion. That way your class will look as original class, so it will use the same options.

 

Second, you need to register your class:

 

uses
  ESend;
 
initialization

  // Register send class to be the first in the list.
  RegisterSenderFirst(TELTrackerMantisSender);
end.

 

The TELTrackerMantisSender class in the example above is your class, which you have derived from default EurekaLog class.

 

The important piece here is to register your class as first, which is archived by using registering function with "First" suffix. Default class (from EurekaLog) will be listed after your class in registered senders. Any search for class by name will find your class, because it's listed first.

 


 

Now that preparations are completed - you can customize your class in any way you want, by overriding virtual methods. Simplified workflow looks like this (pseudo-code):

 

  Open;
  try
    Login;
    try
      // Issue exists?
      if Search.SendResult = srSent then // = insert new
      begin
        Select; // Optional preparation
        Insert;
      end
      // Modify existing
      else
      begin
        // Issue closed?
        NeedReopen := Read.SendResult = srBugReopen;
        // If not closed:
        if Result.SendResult <> srBugClosed then
          // Increase count, upload bug report (duplicate) or reopen
          Edit(NeedReopen);
      end;
    finally
      Logoff;
    end;
  finally
    Close;
  end;

 

You can check sender interface declaration to determine method that you need to override and invoke (available in all EurekaLog editions). You can also check implementation for details (for EurekaLog Enterprise edition only).

 

 

Changing properties

For example, if you want to replace a bug title:

 

  protected
    function ComposeTitle: Stringoverride;
  end;
 
// This is a default implementation of the method,
// you can replace it with arbitrary code
function TELTrackerMantisSender.ComposeTitle: String;
begin
  if BugAppVersion <> '' then
    Result := Format('%s (Bug %s; v%s)', [BugType, BugID, BugAppVersion])  
  else
    Result := Format('%s (Bug %s)', [BugType, BugID]);
  Log(Format('Title = ''%s''', [Result]));
end;

 

This example overrides ComposeTitle virtual method and calls inherited helper methods BugAppVersion, BugType, BugID.

 

 

Altering the behavior

For example, if you want to disable merging bug reports by BugID:

 

  protected
    function Search: TResponse; override;
  end;
 
function TELTrackerJIRASender.Search: TResponse;
begin
  Finalize(Result);
  FillChar(Result, SizeOf(Result), 0);
 
  Result.SendResult := srSent; // indicate a new Bug should be posted
end;

 

Note: while it is a popular question, we do not recommend to do so.

 

 

Tracker-specific changes

Some changes will require you to write code that is specific to the bug tracker that you are using. For example, Mantis uses SOAP wrapper from EMantisConnect/EMantisConnectStub units:

 

function TELTrackerMantisSender.Search: TResponse;
var
  Issue: IssueData;
  X: Integer;
begin
  // Call default EurekaLog's code
  Result := inherited Search;
 
  // Issue exists (found)?
  if FBugEntryID > 0 then
  begin
 
    // Read the issue
    Issue := FMantis.mc_issue_get(TrackerLogin, TrackerPassword, FBugEntryID);
 
    // Search for the parent-child link
    for X := 0 to High(Issue.relationships) do
      if Issue.relationships[X].type_.name = 'child of' then
      begin
        // Follow the link
        FBugEntryID := Issue.relationships[X].target_id;
        Break;
      end;
 
    // Don't forget to update the Result
    Result.IssueID := FBugEntryID;
  end;
 
end;

 

This code will replace the found bug to its parent. Not really useful in practice, but good as a simple example.

 

Jira will use JSON API, Fogbugz will use XML API, etc. It is good to have EurekaLog's source code to see how API is invoked by EurekaLog.

 

 

See also:




Send feedback... Build date: 2024-09-30
Last edited: 2023-07-18
PRIVACY STATEMENT
The documentation team uses the feedback submitted to improve the EurekaLog documentation. We do not use your e-mail address for any other purpose. We will remove your e-mail address from our system after the issue you are reporting has been resolved. While we are working to resolve this issue, we may send you an e-mail message to request more information about your feedback. After the issues have been addressed, we may send you an email message to let you know that your feedback has been addressed.


Permanent link to this article: https://www.eurekalog.com/help/eurekalog/how_to_change_send_workflow.php