Idea Details

CA DataMinder: Change the behavior of the start date from using 01/01/1753 to the date the user was

Last activity 06-03-2019 08:44 PM
PraveenDevershetty's profile image
04-22-2015 12:24 PM

Summary of Enhancement
Change the behavior of the start date from using 01/01/1753 to the date the user was added

How you think the product works:
When a user is added to CA DataMinder for the first time the start date is set as 1/1/1753, essentially the beginning of time (as far as an Oracle database is concerned). This resulted in showing up the emails that were captured prior to adding the user in the reviewer's queue. The reviewer is not be responsible for reviewing the emails that were captured prior to adding him to the DataMinder.

How you would like the product to work
The behavior of initial user creation should be altered to use the state date/time that the user was created instead of the beginning of time (1/1/1753). This way, we can make sure that the reviewer can see only the emails that were captured after the user was added to the DataMinder.


04-20-2016 10:58 AM

Yes, that's the process Praveen has employed for this situation.  We've also looked at tinkering with the database directly, but that's "unsupported" option. 

04-19-2016 10:38 PM

A workaround for this would be to alter your hierarchy process to create the user in a "staging" group first, then move them in the final group they will exist in for review. This would effectively associate the date with the first group, and populate the date of the move for the user when they get put in the new group.


let me know if this makes sense, it's an easy workaround that I think meets your needs.

04-01-2016 11:49 AM

Support does not manage Ideas posted on the community forums. Product Management(kumhe02) would need to provide an update as to whether or not this has been added to the roadmap for inclusion in a specific future release.

03-22-2016 02:44 PM

Support Team:

Any update on this request?




03-22-2016 02:43 PM


Any update on this request?

01-04-2016 08:28 AM

From: []
04 January 2016 13:10

I agree, this should be a configurable option.


06-10-2015 11:09 AM

This was reviewed on June 4th. We do see this as a good enhancement for a future release. The status of this will be updated.

05-22-2015 10:27 AM

Thank you for your contribution of an enhancement idea to the CA Community. CA is continually working to improve its software and services to best meet the needs of its customers.  Your input is vital to that effort.  The CA Data Protection Product Management team will be reviewing your enhancement suggestion. The Community will continue to be able to vote on this enhancement idea.

Will we start the review process on June 4, 2015

05-15-2015 09:42 AM

I second that.

05-06-2015 11:40 AM

Exactly, not looking for a global change, just the option for customers to select the desired behavior. 

04-27-2015 10:31 AM

We have done this for at least one customer in the past, created a customized script that would change the view to use the startdate instead of effectivedate.  I can see the value in both options, so a configuration to choose which you want to use would be nice.

04-24-2015 10:45 AM

Classification: Internal

Hi James,

We had a meeting with Joe Sciortino, Rich Warfield and Robert Sprague on this issue. Please speak to one of them to get more details.


Thanks & Regards,


Praveen Devershetty

Standard and Poor's

55 Water Street, 42nd Floor

New York, NY 10041

(212)-438-7207 (Desk)

(732)-579-7384 (Cell)

04-24-2015 05:17 AM

A global change may not work for everyone. If I recall correctly this was actually by design.

What is needed is an option to create a switch for the WGN_V_GROUP_HIST_x views to allow you to choose the underlying column returned by the EffectiveStartDate as either:

a) The EffectiveStartDate (As now)

b) The StartDate





SELECT UserGroupUID, StartDate, UserIDM,... StartDate As EffectiveStartDate, EffectiveEndDate

FROM ...


This would then propagate through the entire view stack, so would need significiant testing as this would have considerable impact...