If FIM exports to an adapter whose connector has a non-key field set as required but the FIM MA does not (ie connector changed after xMA was generated) and that field in FIM is null, the export action will not be successful but no notification or error message is generated.

Hey Guys,

This request has come as a result of the deletion issues experienced at APRA on the weekend.

Is it possible to implement a feature to abort a connector import / change detection run if an unexpected number of deletes are imported?

I'm thinking something along the lines of a flag to enable/disable, and a threshold value (either a number of entities, or percentage value).
Ideally this would be configurable per connector (as some may legitimately and regularly experience large changes in existing data).

This kind of issue has happened previously on other sites, and a feature like this could prevent temporary data issues within a source system from having impact on downstream systems.

SQL server "Date" type is not supported?

I have one field of type Date in SQL server.

But on import into Identity Broker, using the default field type that is configured for the schema provider (date), validation fails.

The dashboard should have a counter for the number of connectors and adapter.

The schedule for {{DeleteChangeLogsJob }} added in v5.0.0 is not configurable. Due to different requirements for each client, the duration and frequency of clearing out change logs should be configurable.

• 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.

When a CSV connector is created with an invalid path, even after updating the connector to the correct path the Request Schema function still attempts to retrieve the schema from the old (invalid) path.

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.