Difference between ContextTypes : RoleProperty (then contextstring) and Contextstring directly

(0) Share

Report

Posted on by Community Member

Hi all,

I am trying to understand the difference between :

- Applying a security Policy using RoleProperty as contexttype then entering a contextstring in the roles to apply the Policy on the desired roles

- Applying a security Policy using Contexstring as contexttype then entering a contextstring in the roles to apply the Policy on the desired roles

I've read the doc and here's the description of both functionalities, that still does'nt help me to understand the difference, if someone can explain it with an example it would be great.

ContextString – Set the property to this value if a global context is to be used to determine whether the policy should be applied. When required, this context string needs to be set by the application using the XDS::SetContext API.

RoleProperty – Set the property to this value if the policy is to be applied only if the user is a member of any one of a set of roles that have the ContextString property set to the same value (see Setting the policy context later in this article for details for more details).

Thanks to the answerer.

*This post is locked for comments

I have the same question (0)

All responses (12)

Answers (1)

Sohaib Cheema 49,438 User Group Leader on at

Like (0)

Report

In simple words:-

Role Property:

Means you will define name of Role, for which Security Policy will be applied. e.g. Account Receivable Manager, i.e. any policy will be applicable to a specific role only, which you will select at policy level

ContextString:

This concept is like WIFI, anybody having password of wifi can access this wifi.

similarly any role having that contextstring will be effected by that security policy.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Thank you very much for answering,

I think that your definition for Role Property is the one for Role Name isn't it ? If not, then what is the difference between Role property and role name ?

Here the explanation found in Dynamics documentation :

7. Set the ContextType property to one of the following:

 ContextString – Set the property to this value if a global context is to be used to determine whether the policy should be applied. When required, this context string needs to be set by the application using the XDS::SetContext API.

 RoleName – Set the property to this value if the policy should be applied only if a user in a specific role accesses the constrained tables.

 RoleProperty – Set the property to this value if the policy is to be applied only if the user is a member of any one of a set of roles that have the ContextString property set to the same value (see Setting the policy context later in this article for details for more details).

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Nobody can help ?

Was this reply helpful? Yes No
André Arnaud de Cal... 301,168 Super User 2025 Season 2 on at

Like (1)

Report

Hi,

The ContextString is intended to be used in x++ code to enable/disable policies.

The RoleProperty is defined as context string on the roles. You can then link multiple roles to one or more policies with a certain context string.

The RoleName is used to have a policy enabled for just one particular form.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Hi,

Thank you very much for answering,

I am going to try to give more details about what I am trying to do, the testing I've performed and my interrogations.

- The goal is to filter 2 tables (PurchTable, PurchReqLine) on fields that they don't have (Site) using policies via table relations (with InventDim and InventSite) and constrained tables WITHOUT FILTERING InventDim and InventSite.

- The set up is done as described below :

- Query on InventDimSiteID_Site1 (then Site2 and so on)

- Primary Table = InventDim

- Policy InventDimSiteID_Site1

ConstrainedTable = Yes

Table = PurchReqLine

Table Relation = InventDim

- Query on InventSiteSiteID_Site1 (then Site2 and so on)

- Primary Table = InventSite

- Policy InventDimSiteID_Site1

ConstrainedTable = Yes

Table = PurchTable

Table Relation = InventSite

- To apply these 2 Policies on the Role I created the contextstring :

- PurchReqLineAndPurchTableFilter

Now when I apply these Policies using :

- ContextType = RoleProperty then the contextstring above

-> THE FILTER APPLY ALSO TO PRIMARY TABLES

- ContextType = Contextstring then the contextstring above

-> THE FILTER DOES NOT WORK

Thank you for reading and for your answer (I am also interested in any document that provides information about ContextType = ContextString

Best Regards,

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Anyone ?

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

HELP Please

Was this reply helpful? Yes No
André Arnaud de Cal... 301,168 Super User 2025 Season 2 on at

Like (0)

Report

Hi,

I cannot understand clearly what you have done and where you have applied what context strings, what role or roles are involved or not. Maybe you need to elaborate.

The only risk, consequence would be that there is too less or too much data filtered. You should test carefully like any other customization before applying changes to your production environment.

In the past years I have not found a good document related to the property contexttype.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Hi André,

Thank you for answering,

I've tested carefully and to making it simple :

- with contexttype RoleProperty it filters much more data than wanted (it filters the relation table I use to filters the table wanted)

- with contexttype contextstring it DOES NOT filter the tables I wish (however I don't understand the difference between these two functionalities)

BR

Was this reply helpful? Yes No
Verified answer

André Arnaud de Cal... 301,168 Super User 2025 Season 2 on at

Like (0)

Report

As mentioned before, the contextstring option needs to be enabled/disabled using x++ logic. Where in the system did you implement this?

Was this reply helpful? Yes No