Hello,
>i dont want that use to be able to open any other screen especially from the search option.
"Indirect" option might help your reqirement.
I think there are roughly Two ways to create a permission set.
The first is to PILE UP the privileges you think you need. The second way is to CUT DOWN the privileges you don't want to give.
The first method "PILE UP" is to assign the Out-of-Box privilege set provided by Microsoft to the user, test the actual operation by the user assigned the permission set, and add any missing privileges. To find out which permissions need to be added, the permissions recording feature can be useful.
The advantage of this method is that Microsoft will adjust the Out-of-Box permission set in the update, and as Zhu mentioned, sometimes major features like Timesheets are changed in major updates. In such cases, the deleted table or page object will be removed from the Out-of-Box permission set. And also the added table or page object will be added to the Out-of-Box permission set.
This is very convenient, but in other words, you are trusting Microsoft's permission sets, or having a deep understanding of the content of the Out-of-Box permission sets. Unfortunately, I have not been able to find any Docs that fully explain the contents of the Out-of-Box permission set.
The second way "CUT DOWN" unnecessary permissions is to first create a Super-like permission set that specifies all the objects (tables, pages, codeunits, etc.) one by one, and then delete the permissions of the objects you don't want to grant. For example, if you don't want to grant the Modify permission to General Ledger Setup, you can remove the Modify permission of Table Data:98. You can use the permission recording feature to identify the objects you want to remove.
The advantage of this approach is that you can make all the decisions yourself, and you don't have to worry about not knowing the contents of the Out-of-Box permission set. On the other hand, the disadvantage of this method is that you may give users "dangerous" permissions that you should not give them. Can you list ALL the setup related tables?
You also need to keep track of the objects that have been added and changed in major and minor updates.
I think the practical solution is to give up on the exact identification and repeat testing and adjusting permissions. This is a similar idea to the first method.
Or " Accept giving users slightly risky permissions. Or "offer to give users slightly risky privileges. This is closer to the second approach.
I hope this will help you.
Thanks,
S.Kawamura
