cancel
Showing results for 
Search instead for 
Did you mean: 

How do i make 'Valid to' and 'Valid from' fields in Lock user request editable?

Former Member
0 Kudos

Hi,

We want the 'valid to' and 'valid from' fields to be editable in Lock user workflow. The issue is that in all other workflows (create user/ change user, etc) the fields are editable.

I checked the EUP assigned to the lock user request, but there is no setting available there.

Also, checked the 'Action' assigned in Request type for lock user request. We have selected "Lock User", "Unlock User" actions.

In MSMP, we have checked "Change request details" in the stage settings.

In spite of this, the fields are not editable while request submission (end user) as well as the stage (approver).

Can someone help me out here?

Regards,

Arti Sachdev

Accepted Solutions (1)

Accepted Solutions (1)

patrick_weyers
Participant
0 Kudos

Hi Arti,

What is it that you want to achieve?

A user in a SAP system can either be in an unlocked status or locked status - but you cannot assign a validity date to the locking status (in contrast to the user account validity or the role validity). This is not a limitation of GRC, but implicit to the backend SAP system. Hence, it does not make any sense to have this field editable.

If you want to ALSO change the validity date of the user using your LOCK ACCOUNT request, you also need to assign the action to change user details.

The Lock User action will do exactly that: Lock the user.

Additionally, I don't see why you have both Lock User and Unlock User action in your request type for lock user.

Former Member
0 Kudos

Hi,

the reason why i want 'valid to' and 'valid from' editable is that the user might raise a request today for locking a user from some future date.

I added "Change user" action in my request type for Lock user and it worked.

Thanks a lot!

Regards,

Arti Sachdev

patrick_weyers
Participant
0 Kudos

Great that it now works as per your requirement.

Mind you, this still won't lock the user at some future date IMHO. That would require GRC to keep a memory of requests it needs to provision in the future (that functionality does not exist) because you cannot provide a validity date to a locking status.

What you are doing now, I assume, is limiting the validity date of the user account with the "Change User" action - which is perfectly fine! But it's good to understand that the user (although not accessible due to a future validity date) is not technically in a "locked" status.

Answers (0)