I have a attribute named LastPwdUpdateDts which as named stores the last date user changed the password. Businees logic is that after 90 days the password will expire, there is no DB attribute which stores the expirydate.
We need to schedule bulk task and add the date filter which says pick all users whose lastPwdUpdateDate is going to expire in the next 7 days. and then a email policy should start sending send Password expiry notification 7 days before the password expiry date(logical attribute). This logical attribute is not present during the bulk task creation.
For example:
| LastPwdUpdateDts | Today Date | operator | Day offset | Result |
|---|---|---|---|---|
| 29.03.2017 | Today or earlier | 83 | Any date on or before 20.06.2017 | |
| 29.03.2017 | Today or earlier | -83 | Any day or or before 05.01.2017 | |
| 29.03.2017 | Today or later | 83 | Any date on or after 20.06.2017 | |
| 29.03.2017 | Today or later | -83 | Any day on or after 05.01.2017 |
Now for example:
If the LastPwdUpdateDts is 05.01.2017 which is exact 83 days minus today, it would qualify if i use the rule #4 but would fail since it would still pick user whose password was updated on 29.03.2017.
Please note as of now this attribute is the only one customer wants to user. I feel having a Password expirydate would certainly make things easier but customer feels we can still work with only this one LastPwdUpdateDtas attribute and get the correct result.
Please fill in to prove him or me right.
Well actually option #2 worked which is Today or earlier with -83 which would basically mean any date 83 days from today or even before that would qualify for password expiry and notification mail would be sent. I dont know how or why I missed this, may b I got confused.