Announcing the Saviynt Knowledge Exchange unifying the Saviynt forums, documentation, training,
and more in a single search tool across platforms. Read the announcement here.

How to hardcode that requestor cannot change start or enddate when requesting Access

Community_User
Saviynt Employee
Saviynt Employee
Originally posted on November 24 2020 at 14:34 UTC

Hi!


I have following setting to have hardcoded enddate setting for all entitlements in Endpoint.


image



The users are requesting access, how I ca hide(prevent that users can to modify start ad eddates when requesting Access via ARS?

image


best regards, Päivi


This message was previously posted on Saviynt's legacy forum by a community user and has been moved over to this forum for continued exposure.
5 REPLIES 5

Community_User
Saviynt Employee
Saviynt Employee
Originally posted on November 27 2020 at 09:02 UTC

Hi Paivi,


There is no option to prevent edit start and end date. But if you looking to restrict end date then there is option to define maximum difference between start and end date. if requestor enter date more than define max differece between start and end date than pop up will display with appropiate message (The difference between End Date and Start Date cannot be greater than xx hours).


Sample Config JSON for Request Dates : {"ENDDATEREQUIRED" : "1", "DEFAULTTIMEFRAMEHRS": "2", "MAXTIMEFRAMEHRS": "3"}

This message was previously posted on Saviynt's legacy forum by a community user and has been moved over to this forum for continued exposure.

Community_User
Saviynt Employee
Saviynt Employee
Originally posted on December 1 2020 at 08:42 UTC

Hi!


I did set JSOON for Request Dates: {"ENDDATEREQUIRED" : "1", "DEFAULTTIMEFRAMEHRS": "1460", "MAXTIMEFRAMEHRS": "1460"}


and I requested access(as admin) and Start Date was: 01-12-2020 - end date was: 01-31-2021, I was able to change end date to be 05-31-2021 and I was able to save this change and send it to approval? I was also able to approve this request? I tested also by locking as a end user and requested access. same thing I am able to see end date more then 1470 hours?


image



Best Regards, Päivi



This message was previously posted on Saviynt's legacy forum by a community user and has been moved over to this forum for continued exposure.

Community_User
Saviynt Employee
Saviynt Employee
Originally posted on December 1 2020 at 10:01 UTC

MAXTIMEFRAMEHRS=1460 property means it will not allow to set more than 1460 hour. but minimun you can set any date. this is working as per design .


Can you please write your business use case?.

This message was previously posted on Saviynt's legacy forum by a community user and has been moved over to this forum for continued exposure.

Community_User
Saviynt Employee
Saviynt Employee
Originally posted on December 4 2020 at 11:16 UTC

Hi!


1) Requestor is requesting Account/access and precalculated enddate is visible together with start date(2 months from startdate)


2) When requesting Account and Access. Requestor should not be able to change enddate to be more then maxtimframe 1460, e.g. if startdate is 1.12.2020 and enddate is 31.01.2021, enddate cannot be changed to 1.2.2020 or 31.2.2021 or 31.5.2021 etc...



When having this setting in Endpoint in Entitlement Type and in Config JSON for Request Dates:

{"ENDDATEREQUIRED" : "1", "DEFAULTTIMEFRAMEHRS": "1460", "MAXTIMEFRAMEHRS": "1460"}


I am still able to change Enddate from January to example March April .... June .. September .. 2021 etc?


Is this logic working in 5.5 version or only in SP3?



Best Regards,Päivi


This message was previously posted on Saviynt's legacy forum by a community user and has been moved over to this forum for continued exposure.

Community_User
Saviynt Employee
Saviynt Employee
Originally posted on December 4 2020 at 11:18 UTC

I am also able to send this request and it is approved and generated as Task.


Best Regards, Päivi

This message was previously posted on Saviynt's legacy forum by a community user and has been moved over to this forum for continued exposure.