Meaning you can set the security in the AOT with the table properties. Like this
Now the appropriate rights are effective for the security groups a user is member of.
But... (There had to be a but, otherways there wasn't a blog post about this subject, right?)
These temporary tables don't show up in the list when assigning rights to security groups.
Strangely enough, there are multiple temporary tables in the AOT with a security key attached to them. For example tables TmpDimTransExtract, TmpInventBalance, TmpInventAge, TmpPackMaterialFeeSum, ...
When a non administrator user has use of them, he or she will get an error like this:
(for example when you run a report based on a temporary table)
Unable to run report xyz due to access restriction in table ABC.
Object 'ReportRun' could not be created
I see 2 ways of solving this issue:
1) Remove the security key in the table properties
(Wether it makes sense to setup a security key to a temporary table in the first place is an interesting discussion.)
2) Change some code, either in the SysDictTable class or the SysSecurity class.
With this modification, you can assign rights for temporary tables to the user groups, just like you can with "normal" tables.
For the SysDictTable class, change the allowSecuritySetup method. Comment out the call to isTmp().
Alternative: For the SysSecurity class, change the expandSecurityKey method.
Make sure the AllowSecuritySetup method for SysDictTable isn't called for temporary tables.
This is a bit of a contradiction in Ax. According to the code, security is not expected to be setup for temporary tables. You cannot assign rights to user groups for them. But in the SYS layer of the AOT, there are a few temporary tables setup with security keys.
(If you've already openend the user group permissions form, you may have to restart the client after the above modifications, as the information in this form is cached.)
