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.)
In my opinion it's a bug that some of the temporary tables are given security keys. Given the nature of temporary tables, there is only yourself to add data to the tables, so why restrict access to those.
ReplyDeleteYou would restrict access to the process generating the data, if the user aren't supposed to add the data in the first place.
I totally agree with you.
ReplyDeleteThanx for the comment.
Hi Palle,
ReplyDeleteI ran into this blog / issue and found it most intriguing.
The thought crossed our mind to remove the security keys from those temporary tables ;)
Then I found the AX Security Administration Best Practices which states:
Always grant full control to the Parent security keys. You can then take away rights below.
This ensures rights to any temporary tables needed
Create a base security group that only has full control to the Parent keys but not the Child keys
Always use this base security group when creating new groups and then tweak
Tried it and gave full control to the Inventtable parent node, removed all sub nodes and processed the appropriate sub nodes one by one 'et voila' problems I had before with tmpinventage calling a report were gone!
Keep up the good blog!
Mike Dole
nice thanks it solved my error
ReplyDeleteThanks Nickneem! It was helpful to me too.
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteStill a good post in 2015. I will add this is definitely a bug. Mentioning a workaround for it in the Security Best Practices Guide doesn't change that. Architecturally you should never have an option that act thes same at the point it set in code/configuration (AOT table Security Key option) as similar objects (Permanent Tables), then behaves completely different at the point it's configured (Group Permissions). Telling people to assign Full Control at a parent then stripping away access object by object is not a Best Practice. That's a workaround for a bug that creates an inordinate amount of work to compensate for bad design. Instead of just assigning a handful of objects access rights, it requires setting rights on dozens and dozens of objects that have to be individually set to No Access. In addition to that added workload, that introduces the risk of applying too much security elsewhere. It's much easier to find places that access needs to be increased, and much, much more difficult to find where too much access was accidently granted just to make Forms with Temporary Table data sources function properly. Fine if you want Security Keys for Temporary Tables as an added layer of data protection, but then you need to be able to configure security for it just like a Permanent Table.
ReplyDelete
ReplyDeleteThank you very much for sharing such a useful article. Will definitely saved and revisit your site best MS-500T01: Managing Microsoft 365 Identity and Access