Curently it's possible to change the MaxValidDays for existing AccProducts. If there are already ITShop request for that product, these requests are changed automatically as well (set a new ValidUntil).
But the behavior is inconsistent. If the MaxValidDays already had a value, which was changed to another value, nothing happens with existing requests. If the MaxValidDays was changed from 0 ("unlimited") to a value, the ValidUntil in the existing active requests are changed in 2 different ways:
1) If a request has a ValidFrom, the new ValidUntil is calculated based on this ValidFrom.
It can happen, that the new ValidUntil is in the past. The result is, that such a request will be aborted immediately. This is correct, because with the new MaxValidDays you have defined a limitation of the lifetime of requests. But, this can lead to unexpected aborts of requests.
2) If a request does not have a ValidFrom, the new ValidUntil is calculated based on <today>.
This keeps the requests active (which is sometimes intended), but it violates the defined limitation.
Because it's not possible to implement a generaly correct behavior, the correction of the ValidUntils in the requests should not happen automatically in the background. Instead, the modification of MaxValidDays should only be possible with a method, that asks the user, what should happen with the active requests.
Options could be:
1) Keep them untouched
2.) Correct the ValidUntil based on the intial request date - with the potential consequence, that some requests could be aborted immediately.
3. Correct the ValidUntil based on <today>.
An enhancement request (#648979) has been created.
WORKAROUND
None
STATUS
The product team will evaluate the request and this feature may become available in a future release of the product.
© 2026 One Identity LLC. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center