RTC permissions and roles

kaelaa

Hello,

In classic client, we use an enhanced version of the code overage tool to configure role and permissions. The code coverage logs all user actions and all objects that he needs to access to. For example user could do what he'll do normally :
-create new sales order
modify sales order
release sales order
post sales order
etc

the code coverage would give all the objects that this specific role would need to have access.

This method saved us a lot of time in the impementation process.

Now in RTC, we have pages and cues that could not be logged with RTC. Is there anything equivalent in RTC for the code coverage?

I know that wirh RTC we have sample roles and permissions but as we all know these won't fit with every business process. These would need a lot of tuning which will be very time consuming!

I am interested with any ideas and suggestions..

How are you guys doing it?

Is doing it manually the only solution?

Thanks you very much for your help!

pdj

We use a simular tool based on the Client Monitor instead of the Code Coverage. (We normally give full access to all objects except tabledata and system). This tool doesn't work with the RTC either, but I have considered making a solution that could do it based on the result from a SQL Profile recording. Could that solve your problem?

kaelaa

Thanks
Yes this would help!!

So if I understand correctly, you would give access to everything (pages, forms, codeunits, tables)
but you won't give access to TableDATA and system
and with SQL Profiler you would determine to which TableData you would give access?
Can you give me more detail please?

Thanks

pdj

Well, not much to add. I'm not going to make the tool for you 8)

Having the permissions only on tabledata, and not on the page/form/report/codeunit is the same approach as the default roles in NAV. You loose a bit of flexibility, but it is a LOT easier to maintain.

Regarding the tool, I guess I would do like this:

Setup a SQL-Profiler recording, filtered to a single users connection ID
Let the user do whatever he/she should be allowed to do.
Once completed the result should be saved in a SQL table.
Then I would open the table in the SQL designer to get all fieldnames and fieldtypes
Then I would create an identical table in NAV and mark it as LinkedTable=Yes and DataPerCompany=No
Finally a report asking for Role-ID, and it should then go through the SQL-Profiler table and create the permissions needed for the different SQL statements.

That should do the trick.

kaelaa

Okay thanks!

Very appreciated!

If anyone has other ideas, please let me know.

Thanks

kaelaa

I am just thinking, what will happen with indirect permission?

If you give access to all forms, pages, codeunits.. users will be able to modify table data even if they don't have permission because the codeunit has a indirect permission for example...

pdj

kaelaa wrote:

I am just thinking, what will happen with indirect permission?

Say you give full access to the G/L Entry tabel to a user based on the tool. That doesn't allow the user to modify records from the object designer or any dummy form - the customer's licenser will prevent that. These records can only be modified by objects having permissions to the table as well.

Or am I missing your question? Please come with an example...

kaelaa

Okay let's say I create a new table (50000) and a new report (50000)

In the Report, I modify the table 50000 and I give Indirect Permission to modify Table Data 50000

ans let's say that I have a user that shouldn't be able to run Report 50000 and should not modify Table 50000.

With your solution, we give permission to all users to all reports but we don't give him permission to Table 50000 because it did not appear in SQL Profiler.

Since he has permission to Report 50000, he will be able to modify Table 50000 even if we don't want him to...

Am I right?

pdj

kaelaa wrote:

Am I right?

No, the permissions in the object is not enough. The user also needs atleast indirect permissions to the table to be able to modify it with the report.

But if you have two reports modifying the same table and one of them have permissions for it. Then one of the reports requires full permissions assigned to the user, while the other report will work if just the user has indirect. That might result in wrong permissions, but I doubt this approach is used that often.

kaelaa

Okay thanks for your help!