Dynamics F/SCM Customer Experience (CRM) Dynamics GP Dynamics Business Central (NAV) Dynamics SL Power Platform Fabric Copilot

[Predrag Nikodijevic]

Hi developers. Any idea, why would ‘find’ method of the class work for one role, and not for the other? i cant see any permissions on the table, nor the code permissions for the method. 
it looks like this:

    projInvoiceTable = ProjInvoiceTable::find(projTableLocal.ProjInvoiceProjId);
    projSalesCurrencyCodeLocal = projInvoiceTable.CurrencyId;

so for one user/role, it finds the projInvoiceTable, and gets the right CurrencyId, and for others it doesnt, and the ProjInvoiceProjId is there all the times.
where should i look for security which would prevent it, or how do i override the security?
Thanks,
Pedja

——————————
Pedja Nikodijevic
Express Scripts Canada
Mississauga
——————————

[Steeve Gilbert]

Hi Predrag,

Did you find which role was causing this?  That may help you narrow down the scope of your research.  Could that be caused by Extensible Data Security (XDS)?

——————————
Steeve Gilbert
Software Development Supervisor
Boa-Franc S.E.N.C.
QC, Canada
——————————
——————————————-

[André Arnaud de Calavon]

Hi Predrag,

Can you share the contents of both roles and tell which role is working and which is not? Like Steeve mentioned, also XDS can play a role here.

——————————
kind regards,

André Arnaud de Calavon
Solution Architect, Microsoft MVP – Microsoft Dynamics Business Solutions
——————————
——————————————-

[Alex Meyer]

Predrag,

You didn’t mention if this was for AX 2012 or D365FO so I will give both scenarios.

Also you don’t specify if this is happening for one role assigned to multiple users or between multiple roles assigned to multiple users. If its happening with one role assigned to multiple users then I would lean towards this being a XDS issue. If its between multiple roles between multiple users then it might be a security issue which I will discuss below.

For AX 2012, because there is no real connection between entry point security and data source security you can go directly to the table level access in this case the ProjInvoiceTable to look for a difference in access between the roles that work and the roles that don’t work.

For D365FO, there is now a direct connection between a menu items access and the access that a user has to the data sources that are tied to it via the form. So you would need to go to the menu item level to look for difference in access. At Fastpath, we have developed a report to show the associations between menu item -> form -> data source which is how I was able to generate this below. But as you can see any of those menu items could give the user access to the ProjInvoiceTable. 

In D365FO, you also have to worry about explicit denies at the table level although they aren’t as commonly used.

——————————
Alex Meyer
Director of Dynamics AX/365 for Finance & Operations Development
Fastpath
Des Moines, IA
——————————
——————————————-

[Predrag Nikodijevic]

Thanks Alex,
it is AX2012 R3 , CU8.
There are multiple user inside one role, where the FIND method is failing, and multiple users with approver and admin role, where it is working. 
I cant see any required permissions on any of the fields for that table…

——————————
Pedja Nikodijevic
Express Scripts Canada
Mississauga
——————————
——————————————-

[Alex Meyer]

So the biggest thing to do would be to compare the table level access between the users where this process is working and users where this process is not working.

I would focus on these tables:
– ProjInvoiceTable
– ProjectAccountingDistribution
– And any table level access that is in the approve TrvExpenses or TrvRequisitions privileges.

Are you using out of box security to assign to these users or custom security?

——————————
Alex Meyer
Director of Dynamics AX/365 for Finance & Operations Development
Fastpath
Des Moines, IA
——————————
——————————————-

[Predrag Nikodijevic]

Thanks Steeve and Andre,
the role that is failing to get the data is for auditor users who are submitting expenses. The role for approvers/admins are bringing back that CurrencyId correctly.
 So far, i can only see that statement as a point where the process goes two different ways. I was suspecting it is about some sort of security, since it is behaving differently for an auditor role – with permission to submit expenses, and for admin or approver role.

This is a part of a workflow. When an user with auditor role submits expense, that expense can be approved, but then it gets stuck in the workflow – with an error indicating that there is no ‘from’ currency to convert from. debugging shows where is the error, and what field is missing the currency code to lead to that error. 

So those 2 lines in the original post is where currency is found for admin/ approver role, and not for user/auditor role.

If it helps, the table in question is ProjectAccountingDistribution, and the field is Currency. Values are assigned in InitFromSourceDocumentLineItem method.

the list of privileges for user is basically all Expense line and header service operation permissions, as well as all expense report service permissions. 
Approver has privileges to approve TrvExpenses and TrvRequisitions.

——————————
Pedja Nikodijevic
Express Scripts Canada
Mississauga
——————————
——————————————-

[Predrag Nikodijevic]

It looks like there was a Policy in place that i was not aware of, where there is a constraint on a ProjInvoice table. I can see the context type set to RoleProperty, but the ContextString is empty. I cant find anything related to that policy in the Roles that are able to access the table . 

If the ContextString is blank, does the policy apply to all roles, or none?

Is there a way to override the Policy rules through the code?

Thanks,

——————————
Pedja Nikodijevic
Express Scripts Canada
Mississauga
——————————
——————————————-

[Alex Meyer]

Pedja,

An XDS policy is a restriction of role based security already assigned to a user, so it would probably be easier to remove the policy. I do not believe you can override a policy via code. Having a blank context string would make me believe it would apply to all roles in the system according to this: http://axinhd.blogspot.com/2012/11/security-policy-property-in-ax-2012.html

One other thing to check would be role permission overrides for the roles assigned to the roles, role overrides existed in AX 2012 and allowed you to override the role based security and directly assigned table level access directly to the role. If you apply an override to a table, the access level for that object is set regardless of the access level specified by duties and privileges assigned to that role.

Here is a good overview of the feature:
https://www.youtube.com/watch?v=jgRNJ6Z7RDY

——————————
Alex Meyer
Director of Dynamics AX/365 for Finance & Operations Development
Fastpath
Des Moines, IA
——————————
——————————————-