• On the Adapter Entity Search page, the hover tooltip for hiding a column says "Hide row".
• Hiding a column actually hides the column one to the left.
• Grouping by a column similarly actually groups by the column one to the left.

Disabling an adapter excludes its details from LDAP schema requests, but a client performing a request on that adapter is successfully completed.

Disabling an adapter should hide it from the LDAP endpoint (ie search requests return no entities, add requests can't find adapter etc).

A disabled adapter should not return no entities (unless it is actually empty), as it may have accidentally been left disabled, which would potentially result in accounts being deleted in downstream systems. Instead, the most appropriate LDAP error code and message should be returned, if possible.

Issues like IDB-553 were alluding to the issue that the results of a transformation is unknown until imported into the IdM solution. This has been fixed up with pre-populating the adapter context, however, it would be helpful to know how a transformation will behave until it's added.

Add a new feature to preview the result of a transformation before adding it.

DN fields are missing from the left-hand-side of the DN template configuration. There is also a small bug where the field temporarily shifts up to the end of the previous line while entering a value. See attached screenshots.

In the DN template generator, clicking 'Add' with the right field empty spawns the separator selection empty, and if committed, causes the separator to be 'null', which breaks everything.

The separator field should always have a default value.

There is currently no warning in the management studio if two or more adapters share the same object class, which breaks LDAP compliance by having multiple definitions in the schema for that object class.

If a connector satisfies the following:

• Implements modify anchor;
• Implements update;
• Uses the connector key to look up the repository entity on update;

The update will fail as the new key won't match the repository entity.

See if the matching entities can be modified so that they have the updated key. This was an issue for v4.1, but may not be an issue with v5.0 as the connector doesn't need to look up the entities.

This issue is really 2 issues in one:

• the Copy Connector function causes duplicate Timing id GUIDs to be generated, and
• the presence of duplicate Timing id GUIDs cause the corresponding timing node not to fire the connector when the cycle comes around.

So Richard Green - I have just discovered the cause of FIM issue 133 (and most likely 134 as well) - namely multiple connectors with the same polling id GUID, causing the timer not to fire. How they got there I believe was via the COPY CONNECTOR menu option, and I have just proven this (see comments following this issue description).

In the attached configuration, the GUID 43b343ba-a287-401f-b92a-347d572b80f0 appears on 2 connectors' polling Timing nodes, and the GUID 15c3fa6b-cf9e-4fb5-8724-5eae2027da49 appears on several getAllEntities Timing nodes.

The impact of the GUIDs being the same appears to be that the timings count down and then roll over and nothing happens (nothing executed - no log of execution). This would explain why a number of the connectors hadn't reported any changes between the time they were installed to TEST last Friday, and the time the bug report was raised (Wednesday).

I am wondering how many other IdB 4.* implementations out there have this sleeper? As a result I have assigned a CRITICAL status (due to the potential impact), even though I now know the cause of the problem and have implemented a solution.

Edit: FIM Event Broker has been confirmed to generate new id's, and as such is not going to have this issue.

This issue is a follow on to the now resolved https://unifysolutions.jira.com/browse/IDB-1216

What I'm finding is that if I provision an entry to UNIFY Identity Broker, and then perform a delta import, the entryUUID is not in the list of values returned. This then results in FIM throwing an exported-change-not-reimported error. If however a full import is performed, the entryUUID is present.

Generally this likely won't matter if the entryUUID isn't explicitly being used, but it is an issue if the adapter DN is UID=@idBID and you thus need to set the UUID (as the previously linked to issues final post implies)

I've captured some screen shots of the error and behaviour of delta and full imports

Performing a full sync preview which triggers provisioning that sets some defaults, as well as applies some flows

Export to occur, including the entryUUID (set so that I could also control the DN, pictured)

Errors resulting from a delta import performed after the export (there was a 1 minute gap between the export and running this import)

Missing attribute

What the delta Import brought in

Finally running a full import, which has the entryUUID present

I'd expect that deltas should bring in the entryUUID following a provision. To reproduce it I don't think you necessarily need to be using the entryUUID as part of the DN for the adapter, just select on the MA that as an attribute to be read into FIM and then provision a new record and follow it up with a delta import.

The time offset flag transformation deals with times, but does not have a local setting. To allow for local calculations without having to use the offset, add the local setting.