Skip to main content
Question

How to prevent permission set deletion

  • Jan 12, 2023 4:03 PM UTC
  • 5 replies
  • 235 views

Forum|alt.badge.img+5
  • Sidekick (Customer)

Hi 

Does anyone know how we can  prevent accidental deletion of permission sets?

Apparently. it is possible to delete a permission set which is assigned to users. We see some strange behaviour:

 . Anyone in IT who can maintain permission sets can also delete them,. Even if the user is not granted  the FND_ROLE_API.Delete function, the user can still delete the permission set.

 - This cannot even be prevented  by a custom event on fnd_role as the application wipes permission set assignments from fnd_user_role first and this is not rolled back when the the custom event throws an error. 

This seems like very unsafe application design that we cannot prevent accidental or intentional deletion of permission sets. 

5 replies

Forum|alt.badge.img+13
  • Hero (Partner)
  • Jan 13, 2023 7:47 AM UTC

security_sys.drop_role is the correct sec object which will grant the particular user the delete permission set access

 

 


Link
Superhero (Customer)
Forum|alt.badge.img+23
  • Superhero (Customer)
  • Jan 13, 2023 8:31 AM UTC

Hi @KRTI 

it is true. Therefore I recommend you to  export all your permission sets. Sometimes you do unwanted changes and the permission set doesn’t work properly.

But before deleting the permission set you get a warning message:

 


Forum|alt.badge.img+5
  • Author
  • Sidekick (Customer)
  • Jan 13, 2023 10:59 AM UTC

Hi @Ruchira 

Unfortunately we are still able to drop permission sets even when there are absolutely no grantees on SECURITY_SYS.DROP_ROLE


eqbstal
Superhero (Partner)
Forum|alt.badge.img+21
  • Superhero (Partner)
  • Feb 13, 2023 1:56 PM UTC

@KRTI Do you still have the problem? Did a cache refresh on security help anything?

 


Forum|alt.badge.img+5
  • Author
  • Sidekick (Customer)
  • Feb 13, 2023 2:19 PM UTC

Hi

We created a case with IFS and it turns out that this is not possible. We also tried to prevent this using events, but we were not able to make the event trigger before the permission set had been unassigned from all users.