Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

Опции темы Поиск в этой теме Опции просмотра
Старый 19.05.2017, 19:11   #1  
Blog bot is offline
Blog bot
23,383 / 790 (73) +++++++
Регистрация: 28.10.2006
stoneridgesoftware: Identifying Roles for Security in Dynamics 365 for Operations

With Dynamics 365 for Operations comes change. And change is good, it helps keep us on our toes and gives us an opportunity to freshen up our skill sets. There is plenty of change with Dynamics 365 for Operations and one such opportunity to freshen up my security skillsets recently presented itself.

A client asked what role they needed to add a user to in order for the user to be able to run Process assortments from the Retail module.

The Process assortments link simply popped out a flyout form to run a batch job that executed the Retail Assortments Job.

A Quick Review – Security in Dynamics 365 for Operations

Security in Dynamics 365 for Operations is largely unchanged from Dynamics AX 2012. It’s still focused on role-based security with a minor new layer of Azure Active Directory as an authentication mechanism before the authorization piece. I’m not going to cover how security works in Dynamics 365 for Operations, but if you are interested in learning more, review the following links:
In a nutshell, this is how security is structured in Dynamics 365 for Operations:

Security Changes in Dynamics 365 for Operations

There are a few changes to security in Dynamics 365 for Operations, while not exhaustive, they are:
  • Process Cycles have been removed
  • Record Level Security is obsolete
  • Security changes are stored as data when done from the UI
The root of all security is gained by placing users within a defined Security Role to grant them access to whatever it is they need access to (this is really simplifying security).  In Dynamics AX 2012, the old way of figuring out when a user didn’t have access to something (in this case that something is a menu item), you could do the following:
  • Identify the area the user didn’t have access to
  • Log into Dynamics AX as a sysadmin
  • Right-click on it on the area, select personalize and identify what the object was
  • Open the AOT and select the object (or find the root object)
  • Use the Security tools add-in to View Related security roles report
This is a simplified overview of how you could determine what role a user might need to be added to gain access to an object (form, menu item, etc.)

Identifying What Roles Have Access to An Object

With Dynamics 365 for Operations, things have changed.  The old way of identifying what role(s) have access to an object is different, as the interface and client are different. Let’s circle back to the question at the start of this blog.

What role(s) have access to run the Process assortments job in Retail?

There were two ways this question could potentially be answered:
  1. Use Task Recorder to create a recording of the steps in the process and then use Security diagnostics for task recordings (System Administration | Security) to review required permissions.
  2. Use a developer machine, open Visual Studio and navigate through the AOT to find the object and default roles that have permission.
I started with option number one above, however, I found that the recording simply didn’t provide any security context information since it was a flyout and not a true form:

Here are the recording steps:

And here is what the Security diagnostics for task recordings showed (short version – total bust):

Option number two it is.

Identifying Roles in Visual Studio

To start I did the following:
  1. Logged into a Developer Machined
  2. Opened Visual Studio
  3. Navigated to AOT | User Interface | Menus | RetailMain | RetailITMenu | ProductsAssortmentExploderJobScheduler

First I looked at the Properties window to determine what objects are involved.  In this case, it’s a Menu Item with a type of Action.

Next, I navigated to AOT | User Interface | Menu Items | Action | RetailAssortmentExploderJobScheduler

Then I right clicked on the menu action and selected Open designer

From the designer window, right click on the RetailAssortmentExploderJobScheduler and select Addins | View related roles

And here is the resulting report showing what Roles by default have access to this object thus answering the question what roles a user might need to be added to be able to run the Process Assortments job.

Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
stoneridgesoftware: Configuring Power BI Integration for Dynamics 365 Workspaces Blog bot DAX Blogs 1 07.03.2017 10:04
stoneridgesoftware: How to Configure Access for Scribe Online for Dynamics AX 7 Integration Blog bot DAX Blogs 0 22.09.2016 06:12
atinkerersnotebook: Walkthrough & Tutorial Summary Blog bot DAX Blogs 1 09.09.2013 09:11
axinthefield: Dynamics AX Event IDs Blog bot DAX Blogs 0 01.03.2011 22:11
german_nav_developer: Buildnummern-Übersicht Microsoft Dynamics NAV 2009 Blog bot Dynamics CRM: Blogs 0 04.06.2010 13:21
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Часовой пояс GMT +3, время: 23:56.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.