Changes made in order to satisfy EB-381 have meant that when manual execution is attempted on an operation list, no error message will appear on the UI. Currently, the UI shields the user from doing this unless the user manually browses to the Execute URL. If this occurs, the UI will not inform the user that the operation list has not actually been executed.

In doing a quick check to see if I could upgrade v3.0.0 to v3.0.1 of Event Broker while the service was running (I can - so I've raised EB-437 on behalf of the prospective customer), the installer removed the Start Menu short cut to Management Studio.

Is this by design?

As in SSICT-12, investigate the handling of run profile and management agent names in solution migration scenarios.

From PRODUCT-128 (Identity Broker), it was found that in IE8 that clicking a link outside of a popup (menu popup, not a dialog) would stop the popup from hiding. The link would also not be followed.

A fix in Event Broker would fix Identity Broker as it is a shared component.

Determine whether there is an easy way to have the normal functionality work, otherwise fall back to using the fix from IDB-934.

The height of the log viewer in IE7 is only tall enough for 1.x log entries, this may correspond to a recent change to fix the behaviour in EB-484;

 "sScrollY": "100%",

This change prevented the log viewer from being redrawn incorrectly when text was selected in IE8 and below, and as such is pretty important.

Improved sort order on operation index.

It appears to be ordered by creation date. Can this be alphabetical?

If an export run profile cannot be found for the outgoing operations, it defaults to the first run profile. It should instead default to "none" with "no schedule".

When run, the operation list will always execute the Next operation in the tree, irrespective of whether the success/error status.

The original issue was a misunderstanding on my part, the success status of "Next":

A
...B (Success: Next)
C

Would make C run, even though it isn't a sibling of B.

When modifying an Operation Lists list of operations, there are two ways to add a 'next operation'. The first is the 'New Operation' link at the very end of the list, the other is clicking the gear icon and selecting 'Add a next operation'. Both methods result in the next operation being added to the very end of the list.

Intuitively I feel that if you select the gear icon and choose to 'Add a next operation', the operation should be inserted immediatly after the operation corresponding to the gear icon/popup menu.

There would be two benefits to this
a) Adding an operation near the top of a long list would be a lot quicker
b) The logic in my mind is consistent with the 'Add child operation' which adds the child to the selected node. Given the behaviour of adding a child, I think it is fair to assume that adding a next operation would add it after the selected operation, despite this not being the case.

A work around currently is to add the new operation as a 'child' operation and to then perform a 'promote operation'. This has the effect of performing an insert, and I have found it to usually be quicker than adding a next operation and then clicking 'move operation up' numerous times (the fact the page refreshes after each move makes this cumbersome).

This effects both 3.0.X and 3.1.X.

Create an Email from ADAM plugin.