This is the approach that I have been using successfully to limit permissions to GL Entries and the editing of COA. I need the user to be able to post and use GL Account in journals and transactions, but not have access to any financial data by way of GL Entries. Even to the extent of not through Find Entries.
1. Make certain that all other permission sets assigned completely exclude permissions to Table Data 17 - G/L Entry.
2. Create a permission set to Include Table Data 17 with a Security Filter of "G/L Entry: Entry No. = 0" and Read Permission Yes.
3. Create a second permission set to Include Table Data 17 with only Indirect Permission assigned to Read and Insert.
4. Assign both sets to the user or security group. Since these must both be at the highest level in the hierarchy to work correctly, they cannot be referenced within another permission set. They must be assigned directly. Confirm correct results by using Effective Permissions from the user card.
For the GL Account and other setups where I need to limit insert, modify and delete permissions, I create a permission set that in essence is the Foundation of all other permission sets. This set references many MS provided standard permission sets. In the direct permission of this same set, I exclude table data, some pages, and some codeunits. I ALWAYS try to solve using table data first, but found this is not always possible. I resort to page only when I have exhausted all other options. I also confirm the page I am excluding is the only means to accessing the data and that I don't need to exclude another page. A Table Data first approach is the best approach in my opinion because it removes the need to find all the ways a user has access.
I then reference the above "Foundation" Permission set in a permission set I will ultimately assign to users that gives them back the level of permission needed. As seen below, this can include filters.
I hope you find this helpful and maybe The Righter Way for your permissions also.
Cynthia
