New April Hotfix and more changes for VAT
Check out the latest updates to Microsoft Dynamics GP 2016 and 2018.
Dynamics 365 2019 release wave 2 plan Discover the latest updates to Dynamics 365.Release Plan | Weekly Deployment Notes
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants.Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements.
ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
This post is part of the Hands On With the GP Power Tools (GPPT) – Administrator Tools series in which I am taking a hands on look at the various tools offered by GPPT.
Microsoft Dynamics GP’s security is constructed on a pessimistic security role and task model (users have no access unless granted); an operation (such as the ability to open a window or print a report) is assigned to a task which is, in turn, assigned to a role, which are then assigned to a user or, preferably, multiple users:
This security model is far superior to the optimistic user class model used up to and including Microsoft Dynamics GP 9 before the role/task model was introduced.
As good as the role/task based security model is, it does not lend itself to configuring two users with mostly the same security, but with minor variations. For example, I might want all AP Clerks to be able to maintain vendor cards, but only allow one or two users access to the EFT details.
On the role/task based model, I would need to duplicate the role and remove the task which gives access to the EFT Bank window; or worse, I might also need to create a new task which removed this one operation as well as creating a new role. This can lead to a proliferation of almost identical roles and tasks for throughout Dynamics GP if you have a number of these variations required.
The GPPT feature Deny Based Security (DBS) aims to provide an alternative. DS adds an optional additional layer to the role/task security model, which allows individual resources or operations to be denied on a per user and company basis which overrides the access granted by the standard security role/task security.
DBS also adds the ability to hide items from the menu navigation when those items cannot be controlled by security. This works for both menu items linked to forms excluded from security and menu items which run scripts rather than opening forms.
In addition, the Security Denied functionality, once applied, works whether GP Power Tools is installed or not; the Security Hidden functionality does require the GP Power Tools to remain installed (which is the recommended configuration anyway).
Over the next few posts, I am going to take a look at how DBS works and will close with a review of effective I think it is.
Read original post Hands On With the GP Power Tools - Administrator Tools: Introduction to Deny Based Security at azurecurve|Ramblings of a Dynamics GP Consultant
Business Applications communities