Prevent analyst from reopening ticket if they are the Affected End User

[Tammy Zadell]

Hi everyone,

I thought this one was going to be relatively easy, but...

 

When someone who is defined as an analyst in the system is the Affected End User of a ticket, I want to prevent them from being able to reopen that ticket (change the status from closed to open). 

 

So, I created a site-defined condition and attached it to the closed to open status transition, but it doesn't seem to be working.  Attached is a screen print of the macro.  I know I sometimes get confused with the setting "If all conditions succeed return" -- So I've tried both FALSE and TRUE.  I've also tried reversing the logic by making the macro check to see if the 'Login User equals the Affected End User' and tried both a TRUE and FALSE return, but nothing seems to work.  In all cases the condition error isn't thrown, and I am able to change the status from closed to open.  What am I doing wrong?

 

Thanks,

Tammy

 

[Legacy User]

Hi Tammy,

 

In your sample you're using audit_userid.

Try with "last_mod_by".

 

Regards,

Carlos

[Tammy Zadell]

Hi Carlos,

I thought audit_userid was strange too, but that is what the macro builds automatically when 'Affected End User' is selected as the attribute value.  I can't change the macro code without going through the process of exporting it, changing it, then importing it.  Why would it build the wrong code when the correct attribute value has been selected?

Thanks.

Tammy

[Legacy User]

Hi Tammy,

 

I think when you use "Login user" attribute it gets the "audit_userid".

 

I checked in SDM 17 and "Login user" is an attribute added in this case to Activity Association List.

 

If we check audit_userid definition, we can see that is a local value that means is for store data provisionally.

 

audit_userid         LOCAL SREL -> cnt.id TENANCY_UNRESTRICTED

 

In your case you need add in your Activity Association List the attribute "Last Modified By"(last_mod_by).

 

last_mod_by          SREL -> cnt.id TENANCY_UNRESTRICTED

 

And use this attribute in your site-defined condition as "Last Modified By" Does Not Equal "Affected End User".

 

Regards,

Carlos

[Grant Bruneau]

Hi Carlos,

 

This won't work for Tammy's use case.  What if the last_mod_by user is not the affected end user?  I think it's more likely that the last_mod_by user will be the assignee on the ticket and not affected end user, so I don't think this will give the desired outcome. 

This may be a bug with the audit_userid attribute, we had to stop using it when we upgraded to v17 because our site defined conditions which used it stopped working (they worked fine in 14.1.02).  In our case using last_mod_by worked as well, so we switched our conditions to that attribute.

[Legacy User]

Hi Grant Bruneau,

 

When you change the status on Incident, last_mod_by gets the current user that is doing this action.

 

I think this can work fine for Tammy's use case.

 

I tested on V17 and is working fine for me.

 

Regards,

Carlos

[Grant Bruneau]

Oh I get it, has the last_mod_by attribute been enhanced?  In the past it I had to use audit_userid to get the current user (or maybe we followed bad information).

[Tammy Zadell]

Hi everyone,

Yes, sorry --- I meant to say that audit_userid is what gets built when 'Login User' is selected.  I can try Last Modified By instead, but it's strange because we have another macro using Login User that is working just fine -- that macro checks to see if the 'Login User is not the Assignee' (see below).  

 

if (( is_null(assignee) || is_null(audit_userid) || audit_userid != assignee ))
set_return_data(TRUE);
else
set_return_data(FALSE);

 

Thanks.

Tammy

[Tammy Zadell]

Well, that doesn't seem to have worked either.

 

I created a new activity association for Last_Modified_By (Did I do it right?)

 

Then used that in my macro --- Here is the code:

 

if (( is_null(getval_by_name("customer")) || is_null(getval_by_name("last_mod_by")) || getval_by_name("last_mod_by") != getval_by_name("customer") ))
set_return_data(FALSE);
else
set_return_data(TRUE);

Thanks,
Tammy

[Legacy User]

Hi Tammy,

 

My site-defined conditions is the same as your condition.

 

I create an incident with user A. and Affected End User is user B.

 

 

In my case, affected end user cannot set the status to Acknowledge by himself.

 

 Here my macro:

Here the status transitions with site-defined condition:

 

And here the error when I try to set the status to Acknowledge with user B (ServiceDesk in this case).

 

 

Any difference with your use case?

 

Regards,

Carlos

[Tammy Zadell]

Hi Carlos,

No, no difference that I can see, except that you had "If all conditions succeed return" TRUE.  I changed it to that, and it worked.  So I've just now changed my macro back to being "Login user" not equal to Affected End User, and "If all conditions succeed return" TRUE (which I had tried before), and for some reason now that is working!  I'm not sure what was wrong before, but it seems to be working now...

 

Thanks everyone!

[Tammy Zadell]

One more follow on question about this...

 

Is there a way to use a timespan in a condition?  Like if you wanted to prevent a closed ticket from being reopened if the closed date is greater than 30 days in the past? 

 

Thanks.

Tammy