Hi!

I tested this myself, and I took notice of a particular detail in the error:

There has been an integration error. A Destination contains an invalid filter. Destination: 'ETM TEST - Ad-hoc Tasks' with target: 'ETM_Ad-hoc Tasks Test'. Filter content: 'if ("NORMALTASK" = "NORMALTASK" and [] >= 0, true, false)'

This [] coincides with parentEvent in the message delivery expression, pointing to the parentEvent property being evaluated as null. This will be the case if you’re creating an Ad-hoc Task, which unlike tasks created from workflows, do not not populate the parentEvent property.

IFS Assyst Wiki: Ad-hoc Tasks:

... Note: The Create Task Event option does not create a parent/child relationship between the created Task and the Event it is created from. As the ad-hoc task function does not set the parent ID field on the Task, no value is shown in the Task Parent Monitor Column for ad hoc tasks.

I might be wrong, but I dont think there is a way to get the source event directly from a task when the task is created as an ad-hoc task. 

Some ideas for how to approach:

You could try to get to the source event through a delivery expression by “stepping through” the newly created task’s linkedEventGroup → linkedEvents → linkedEvent etc. chain.

I haven’t tested making such a deliver expression myself, but during task creation, the automatic link to the source event is added by the system before the destination evaluates the new task. As this auto-link seems to reliably exist during evaluation, you should be able to get the parent event and evaluate whether an attachment exists.

This approach also assumes that multi-step evaluations “quit early” if the start of the delivery expression is not responsive, to avoid impacting general performance. This concern seems unwarranted, as the expression you’ve provided did not cause any errors when logging other types of events with this destination active. (I would assume that if the entire expression were evaluated, then other event types would also trigger the same error during logging.)

Alternative approach:

Use ETM to log the ad-hoc tasks based on an action as input, rather than using the Event Monitor → Create Task method. This could act as an easier way for users to create tasks, as when an action is used as the input, you have a direct link to the source event and can easily evaluate the existence of an attachment in the destination delivery expression.

The tricky part with this approach is that you need to manually create the event link between the source event and the task using ETM. You also lose lookup selectors in the Create Task popup, so allowing users to select which service department the newly created event will appear in won’t be possible. Additionally, you lose access to the “Go to Task Form” for filling out a more detailed task.

Third approach (with mixed feelings):

Let ETM handle all the filtering and forego using the destination to check whether the source event has an attachment. This is probably the easiest to implement and lets users keep the regular GUI for creating tasks. However, it has the drawback of “spamming” ETM with needless “success” imports in the ETM imports log even when an import is filtered by the filtering expression. I also haven’t been able to estimate if this is more or less scalable than the other methods. 

Either way, this sort of ETM filtering can be done by first setting the event destination Message Delivery Expression to:

if ($new.eventTypeEnum = "NORMALTASK", true, false)

…and adding some additional data to the message body by setting the destination’s Message Filtering and Expansion to something like this:

[linkedEventGroups.linkedEvents.linkedEvent.[attachments]]

This extra data will become part of the eventual inbound which helps reduce the overall load on the application by preventing ETM from needing to make a separate REST lookup to get info from the source event.

The ETM channel can then be set up to listen to this destination, and using a filter expression on the data mapper(s), you can stop the channel from any unnecessary further processing if the “source event” does not have at least one attachment.

I’ve made a proof of concept filter expression for this last aproach, but not thoulgly tested it yet: 

(function(inbound) {
  try {
    var groups = inbound && inbound.linkedEventGroups;
    if (!groups || !groups.length) return false;

    var events = groups[0].linkedEvents;
    if (!events || !events.length) return false;

    for (var i = 0; i < events.length; i++) {
      var le = events[i];
      var linkedEvent = le && le.linkedEvent;
      if (!linkedEvent || linkedEvent.id === inbound.id) continue;

      var attachments = linkedEvent.attachments;
      if (attachments && attachments.length >= 1) {
        return true;
      }
    }

    return false;
  } catch (e) {
    return false;
  }
})(inbound)

All that said, it would be very nice if there were a more direct way to link an ad-hoc task to its source event without having to rely on these kinds of workarounds to get the desired behavior 😅

I very much welcome it if anyone else has ideas or a more elegant way to solve this 

Best regards,

Richard