Skip to main content

Record level Security Ax 2012


RECORD LEVEL SECURITY IN AX 2012

In this blog we will discuss record level security in Ax 2012. Record level security includes Query, Constrained table, Security policy, Temp table (Optional).  


  1. Create a query That will be used to restrict data access from the Constraint table.

  2. Right-click Data Sources, and the select New Data Source.

  3. In the Table field, enter the primary table name CustGroup.

  4. Right-click Ranges, and then select New Range.

  5. Set the Enabled field to Yes.

  6. In the Data Source field, enter the primary table name, in this case, ‘CustGroup’.

  7. In the Value field, enter 10 to restrict access to data where CustGroup has value of 10, by defining the Range for the CustGroup field.

    In the Value field, enter 10.

Add a new security policy

  1. Add a new security policy. 

  2. Set Constrained Table to Yes. This will also secure access to the primary table. In this example this is the CustGroup table.

  3. Set the Context Type field to RoleName.

  4. Set the Enabled field to Yes.

  5. Set the Operation field to AllOperations. Other available values for Operation include SelectInsertUpdateDelete, and InsertUpdateDelete.

  6. Set Primary Table field to CustGroup.

  7. Set the Query field to the name of the query created above, for example ‘XDSQCustGroup10’.

  8. Set the Role Name field to ‘TradeSalesClerk’. Because Context Type is set to RoleName for this policy, it is required to enter the AOT name for a user role.

    In the Role Name field, enter TradeSalesClerk.

  9. Next, add constrained tables. In this simple example add one table.

    Add constrained tables.

    a. Right-click Constrained tables, and then select New > Constrained Table.

    b. Set Constrained to Yes.

    c. In the Name field, enter the Constrained table, for example ‘CustTable’.

    d. In the Table Relation field, enter the relationship to the primary table, in this case ‘CustGroup’.

  10. As a final step, it is required that you build and synchronize the solution to activate the policy.






  HEY HEY HEY!!!! HACK OF THE DAY
TEMP TABLE USAGE IS OPTIONAL DEPENDING UPON REQUIREMENT AND MAKE SURE TO ALLOCATE CORRECT USER. MOREOVER CONTEXT STRING CAN ALSO BE USED 

Comments

Popular posts from this blog

Edit Method on Form

Edit Method D365 for a form Data Source 1. To create an edit method first create a controller class. with following properties  public static edit MainAccountNum LedgerJournalTransLedger(LedgerJournalTrans _ledgerjournal, boolean _set, MainAccountNum _id) { MainAccountNum accountId = _id; MainAccount mainAccount = MainAccount::findByMainAccountId(_id); if(_set) { if(_ledgerjournal.AccountType== LedgerJournalACType::Ledger) { mainAccount = MainAccount::findByMainAccountId(accountId); if(_ledgerjournal.LedgerDimension) { DimensionDefault defaultDim = LedgerDimensionFacade::getDefaultDimensionFromLedgerDimension(_ledgerjournal.LedgerDimension); _ledgerjournal.LedgerDimension = LedgerDimensionDefaultingEngine::getLedgerDimensionFromAccountAndDim(mainAccount.RecId, DimensionHierarchy::getAccountStructure(mainAccount.RecId), defaultDim); } else { _ledgerjournal.LedgerDimension = LedgerDimensionDefaultingEngine::getLedgerDimensionFromAccountAndDim(mainAccount.RecId, DimensionHierarchy::getAcc

Security Objects In D365

   PRIVILEGES, DUTIES AND ROLES IN D365 FinOps To add customize security privilege, duty and role you should follow this flow because it is considered as the best practices  Role---> Duty---->Privilege Duty and Privilege would be created at the back end and where as role would be created at front end  1. create privilege from solution explorer in a project  and add new entry point for output, display or action menus to refer in privilege that for which entity we have to give privilege to the user 3. Now Create a duty from solution explorer same as privilege and add this new created privilege to the duty  Now you can refer this duty to the role created on the front end.   HEY HEY HEY !!!! HACK OF THE DAY !!           THE HIGHEST ACCESS LEVEL  FOR ACTION MENU ITEM IS   DELETE     

Deep Links

  DEEP LINKS FOR SALES ORDERS In this blog we will discuss about generating deep links for any form , record or datasource. Deep links are basically termed for generating URL's through code for any specific record in D365. Using Deep links other environments can access D365 records by using this URL generated from it. 1. In below blog I am creating Deep links for sales order header record. 2. To Access these links one should always be added the user in FinOps to access through URL. Step #1 Create and extension class of  URLUtility class  and also add following code snippet to access this class : using Microsoft.Dynamics.AX.Framework.Utilities; using Microsoft.Dynamics.@Client.ServerForm.Contexts; public static str generateRecordUrl(str _menuItemName, MenuItemType _menuItemType, DataSourceName _dataSourceName, Map _indexFieldValuesMap, DataAreaId _dataAreaId = curExt()) {   System.Uri host = SessionContext::Get_Current().Get_RequestUrl();   UrlHelper.UrlGenerator generator = new Url