The extended security model is used to create a customer rule for limiting the access to records. In simple words, XDS is placing a Where clause on any SQL Select, Update, Delete, or Insert statement based on parameters from another related table.
Scenario: Users are clubbed in a group and this group is then associated with a Sales Order. A user should only be allowed to view the sales orders which belong to a group where the users is associated.
The different components of the XDS security are :
1. Query: Query created for a table which is then extended to all the related tables where this table is a foreign key.
For the above scenarios because we need to filter the Sales Order, so we will find a table where the Sales Order has a relationship. Eg: ( CommissionSalesGroup ) however the sales commission group does not have users associated to it, so we create a new table ( AFZCommissionSalesGroupUsers ). Now the query that we will create will be based on the table which has a direct link the sales order (CommissionSalesGroup ) and we will restrict this based on a join with the (AFZCommissionSalesGroupUsers) where the user= curUserID()
Next step is to add a security policy object.
2. Security policy: Once the query is designed, the next step is to plan which all table would this query restrict access to. A policy is used to link the query (created in step 1) with a list of tables which need to be restricted for security (constraint tables).
It also has a policy context which is used to determine when the policy is applied, this is generally set to a security role (i.e. anyone which the configured role would be applied with the record level security).
The security policy also has a primary table mentioned which is the root of the query that is created. The primary table should have an explicit relationship with all the tables where the constraint is being applied.
Every security policy would also have a property called Constrained Table which can be set to Yes or No to decide if the policy would be applied on the primary table itself or not.
When the policy is applied on the primary table it be already applied before the xds method is called in MyTables. If the xds method needs access to the records in the primary table, this might be a concern as the policy would already be applied and not all the rows in the primary table would be available for the xds method. In cases like this a view based on the primary table can be created and that should be used instead of the actual table.
Alternatively within the XDS method if the xds needs to be by-passed the below constructs can be used
in AX2012 use
XDSServices.setXDSState(0)
in Dynamics F&O you can use the below code block
unchecked(Uncheck::XDS)
{
select ValidTimeState(_asOfDate) maxof(ValidTo) from hcmEmployment
where hcmEmployment.Worker == _workerRecId;
}
Ensure that you set the Constrained Table property to Yes and add the primary table is set to the primary table of the Query that is attached.
3. MyTables : These are special tables created to be used in the security query, where custom logic can be written to populate data. These table names are prefixed with "My" keyword and the logic is written in xds function.
public RefreshFrequency xds()
{
MyAFZCategory myCategory;
SPYHCMWorker hcmWorker; //view is used as the primary table is contrained
DirPersonUser dirPersonUser;
AFZEmployeeCategory afzEmployeeCategory;
AFZWorkerCategoryUserAccess workerCategoryUserAccess;
insert_recordset myCategory(HcmWorkerRecId)
select RecID from hcmWorker
join afzEmployeeCategory
where afzEmployeeCategory.Code == hcmWorker.AFZCategoryCode
join workerCategoryUserAccess
where workerCategoryUserAccess.UserId == curUserId()
&& afzEmployeeCategory.CodeGroup == workerCategoryUserAccess.CodeGroup ;
/*
select generateOnly forceLiterals RecID from hcmWorker
join afzEmployeeCategory
where afzEmployeeCategory.Code == hcmWorker.AFZCategoryCode
join workerCategoryUserAccess
where workerCategoryUserAccess.UserId == curUserId()
&& afzEmployeeCategory.CodeGroup == workerCategoryUserAccess.CodeGroup ;
info( hcmWorker.getSQLStatement() );
*/
//Calculate current worker value
select firstonly PersonParty, ValidFrom, ValidTo from dirPersonUser
where dirPersonUser.User == curUserId();
select firstonly RecId from hcmWorker
where hcmWorker.Person == dirPersonUser.PersonParty;
myCategory.initValue();
myCategory.HcmWorkerRecId = hcmWorker.RecId;
myCategory.insert();
// This is static data, so only refresh when session is restarted
return RefreshFrequency::PerSession;
}
}
When a table is being added to the constraint table. There are two options:
- Constraint Table : Allows us to select tables from which the data would be filtered. These tables should have a relationship defined with the primary table of the xds query.
- Constraint Expressions: Allows us to select tables and define a realtionship of our own.
In the example below a InventTable is being added to the constraint tables with an explicit relationship (InventTable.ItemID == InventItemPurchSetup.ItemID)
The XDS security policies are saved in the database and hence its important to have the project "Synchronize Database on build" turned on when changes are being done to the security policy. The table where the security filters are saved is ModelSecPolRuntimeEx. This table also stores a
select QUERYOBJECTAOTNAME, CONSTRAINEDTABLE, MODELEDQUERYDEBUGINFO , MODELEDQUERYPACKDATA
from ModelSecPolRuntimeEx
where [Name] like 'AFZ_NonStoppedItemPolicy'
Some times the containers in the database might not get updated and you might get an error as below when the security is applied.
This only indicates that the Query is not updated in the database. To update the required data in the database against a XDS query execute the below code in a job class.
