allenmorris Absent Member.
Absent Member.
601 views

Vetoing on a Date Attribute string


Good Morning All,

I am importing data through a CSV file which will contains a field
called "change date". I what to "veto" any object changes in IDM that
are greater than 30 days old.

I'm thinking of using the !CTIME function in the Time and Convert Time
tokens. Here is what I'm thinking.

Set local variable currentTime = !CTIME (current date)
Set local variable offSetTime = currentTime-2592000

Convert changeDate >> !CTIME (Will the Convert Time Token will see the
string MM/dd/yyyy as a date or just text?)

IF changeDate < offSetTime then Veto.

Is there an easier way of testing a date?

Many thanks,

Allen


--
allenmorris
------------------------------------------------------------------------
allenmorris's Profile: https://forums.netiq.com/member.php?userid=1565
View this thread: https://forums.netiq.com/showthread.php?t=55468

Labels (1)
0 Likes
12 Replies
Knowledge Partner
Knowledge Partner

Re: Vetoing on a Date Attribute string

allenmorris wrote:

> Set local variable currentTime = !CTIME (current date)
> Set local variable offSetTime = currentTime-2592000
>
> Convert changeDate >> !CTIME (Will the Convert Time Token will see the
> string MM/dd/yyyy as a date or just text?)
>
> IF changeDate < offSetTime then Veto.
>
> Is there an easier way of testing a date?


Should work as you describe it.

Easier? You can set your variable offSetTime directly skipping the step
involving variable currentTime as token time has an option to specify an offset
directly.

--
http://www.is4it.de/en/solution/identity-access-management/
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Knowledge Partner
Knowledge Partner

Re: Vetoing on a Date Attribute string

allenmorris <allenmorris@no-mx.forums.microfocus.com> wrote:
>


Let me suggest a variation on this:

The convert time token can include an offset.
So you can convert your source "change date" to YYYYMMDD plus say 30 days

Then just compare this to current time (also in YYYYMMDD) and veto any
events that are less than today.

You can use local variables or maybe even do-reformat-op-attr depending on
what you want to do with the "change date" attribute on events you don't
veto.

By truncating to precision of a day, it is easier to enforce and debug the
original design.

--
If you find this post helpful and are logged into the web interface, show
your appreciation and click on the star below...
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
allenmorris Absent Member.
Absent Member.

Re: Vetoing on a Date Attribute string


Thanks for both those suggestion.

I've gotten the convert time token to work with the MMddyyyy format, but
I'm having a small challenge thought. I can not figure out how to get
the 'change date' into the convert time token.

I set the 'change date' to a local variable tempDate and tried to use
the variable browser, but nothing is added to the 'source format' field
when I choose the variable.

I must be missing something. Might you have a suggestion on where to
look?

Many thanks,

Allen


--
allenmorris
------------------------------------------------------------------------
allenmorris's Profile: https://forums.netiq.com/member.php?userid=1565
View this thread: https://forums.netiq.com/showthread.php?t=55468

0 Likes
Knowledge Partner
Knowledge Partner

Re: Vetoing on a Date Attribute string

allenmorris <allenmorris@no-mx.forums.microfocus.com> wrote:
>

Thanks for both those suggestion.
>
> I've gotten the convert time token to work with the MMddyyyy format, but

I'm having a small challenge thought. I can not figure out how to get
the 'change date' into the convert time token.
>
> I set the 'change date' to a local variable tempDate and tried to use

the variable browser, but nothing is added to the 'source format' field
when I choose the variable.

I think you are struggling with the nesting of dirxml nouns and verbs
concept. Geoffrey explains this well in one of his articles. If that isn't
it then we need more details

Can you post a level 3 trace of at a bare minimum the input prior to this
policy and the policy trace? Traces make it far easier for us to help you.

Preferably would be best with a level 3 trace starting from the input csv
as sent from shim and up until the veto rule.

--
If you find this post helpful and are logged into the web interface, show
your appreciation and click on the star below...
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
allenmorris Absent Member.
Absent Member.

Re: Vetoing on a Date Attribute string


Alex,

Thanks for your reply.

I think I figured it out. I was trying to add the 'change date' field
directly to the covert time token. It works much better when you add it
as an indented local variable noun.

This is one of my first times passing something to a verb, so I wasn't
sure what I was doing. Wish I had found something which explained the
process better.

Still have to do some tweaking, but at lease not getting any errors.

Many thank,

Allen


--
allenmorris
------------------------------------------------------------------------
allenmorris's Profile: https://forums.netiq.com/member.php?userid=1565
View this thread: https://forums.netiq.com/showthread.php?t=55468

0 Likes
Knowledge Partner
Knowledge Partner

Re: Vetoing on a Date Attribute string

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Vetoing on a Date Attribute string

allenmorris wrote:

>
> Alex,
>
> Thanks for your reply.
>
> I think I figured it out. I was trying to add the 'change date' field
> directly to the covert time token. It works much better when you add
> it as an indented local variable noun.


That is exactly what I was trying to explain as your problem.
Glad to hear you worked it out.

This is one of the most common new beginner stumbling blocks with
DirXML-Script policy. You are far from the first to be puzzled by this.

> This is one of my first times passing something to a verb, so I wasn't
> sure what I was doing. Wish I had found something which explained the
> process better.


As Geoffrey mentioned, he covers this in this article:

https://www.netiq.com/communities/cool-solutions/common-mistakes-newcomers-idm-make-part-1/
0 Likes
Knowledge Partner
Knowledge Partner

Re: Vetoing on a Date Attribute string

On 3/4/2016 2:34 AM, Alex McHugh wrote:
> allenmorris wrote:
>
>>
>> Alex,
>>
>> Thanks for your reply.
>>
>> I think I figured it out. I was trying to add the 'change date' field
>> directly to the covert time token. It works much better when you add
>> it as an indented local variable noun.

>
> That is exactly what I was trying to explain as your problem.
> Glad to hear you worked it out.
>
> This is one of the most common new beginner stumbling blocks with
> DirXML-Script policy. You are far from the first to be puzzled by this.
>
>> This is one of my first times passing something to a verb, so I wasn't
>> sure what I was doing. Wish I had found something which explained the
>> process better.

>
> As Geoffrey mentioned, he covers this in this article:
>
> https://www.netiq.com/communities/cool-solutions/common-mistakes-newcomers-idm-make-part-1/


The reason this is funny to me is that I was working with a Uni doing
IDM, and they had a large installation, but were ramping new staff on
and off all the time. I started thinking about things that confuse folk
that the docs do not cover in a way that jumps out at people. (Note I
distinguish here between quality and a different problem - highlighting
what is important, that is a different and harder task).

So I tried starting a series for folk who are learning to read, and
cover stuff that is confusing or hard to find but you should know.

Let me know if there are other topics I missed that confuse you. I have
#12 half written but need more topics to finish it.

0 Likes
Knowledge Partner
Knowledge Partner

Re: Vetoing on a Date Attribute string

Hi Allen,
I use similar logic in number of our drivers (change hiring status, remove records about O365 license after 30 days after termination, etc).

My old code from one of the drivers
<do-set-local-variable name="lvEDSExpirationDate-7yyyyMMdd" scope="policy">
<arg-string>
<token-convert-time dest-format="yyyyMMdd" dest-tz="America/Toronto" offset="7" offset-unit="day" src-format="yyyyMMdd" src-tz="America/Toronto">
<token-local-variable name="lvEDS-LoginExpirationTimeyyyyMMdd"/>
</token-convert-time>
</arg-string>
</do-set-local-variable>
<do-if>
<arg-conditions>
<or>
<if-local-variable mode="nocase" name="lvADExpirationDate" op="lt">$lvEDSExpirationDate-7yyyyMMdd$</if-local-variable>
</or>
</arg-conditions>
</do-if>
0 Likes
allenmorris Absent Member.
Absent Member.

Re: Vetoing on a Date Attribute string


Many thanks to everyone's replies.

It's up and running. The date format yyyyMMdd works much better than
MMddyyyy, especially when you are looking at dates around the new year.
MM as 12 is always greater that 01... can throw a monkey wrench into the
soup.

goeff, thanks to the links to your newbie articles. I think I've read
most of them at least a half dozen times, and I pull up your "Definitive
Guide..." before I start any coding. Thanks a bunch.

Your explanation of convert time though, to me, doesn't fully explain
how to use the noun function for adding data to the Convert Verb. The
example you give only shows the verb itself and nothing else, which did
help lead to a solution. Adding a little about how to interject the noun
into the function would help.
https://www.novell.com/coolsolutions/feature/19503.html

Stay well all,

Allen


--
allenmorris
------------------------------------------------------------------------
allenmorris's Profile: https://forums.netiq.com/member.php?userid=1565
View this thread: https://forums.netiq.com/showthread.php?t=55468

0 Likes
Knowledge Partner
Knowledge Partner

Re: Vetoing on a Date Attribute string

> goeff, thanks to the links to your newbie articles. I think I've read
> most of them at least a half dozen times, and I pull up your "Definitive
> Guide..." before I start any coding. Thanks a bunch.


Good, glad to hear they help. Any other topics you think would help
people? I am out of ideas on what to write next in that series.

> Your explanation of convert time though, to me, doesn't fully explain
> how to use the noun function for adding data to the Convert Verb. The
> example you give only shows the verb itself and nothing else, which did
> help lead to a solution. Adding a little about how to interject the noun
> into the function would help.
> https://www.novell.com/coolsolutions/feature/19503.html


To be fair that is literally an 8 year old article, and note it was for
IDM 3.5, and the Convert Time expansion with offset was added in IDM 3.6.


0 Likes
Knowledge Partner
Knowledge Partner

Re: Vetoing on a Date Attribute string


yyyyMMdd vs MMddyyyy is very true if you do string compare.

I usually convert all time tokens to ctime and do numeric compare, my
problem is that sometimes I forget to switch from string to numeric.


--
joakim_ganse
------------------------------------------------------------------------
joakim_ganse's Profile: https://forums.netiq.com/member.php?userid=159
View this thread: https://forums.netiq.com/showthread.php?t=55468

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.