Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics CRM (Archived) / Hide button based on a...
Microsoft Dynamics CRM (Archived)

Hide button based on access to individual entity

(0) ShareShare
ReportReport
Posted on by KG_CRM

The example at [Hide a standard 'out of the box' button based on a users security roles] shows how to show/hide a button based on if a user has global delete permission of contacts, but how do I have it check the 'Write' permission of just the entity that's open instead of a global permission?  I know to change PrivilegeType to 'Write' but what do I set PrivilegeDepth to?  Do I do anything with AppliesTo?  The button I'm trying to show/hide is on the main form and not a subgrid.

*This post is locked for comments

  • KG_CRM Profile Picture
    KG_CRM on at
    RE: Hide button based on access to individual entity

    I did some more researching to find an alternate method to using the FormStateRule.  Instead of setting a Display Rule for my buttons I read a post from Scott (community.dynamics.com/.../141076.aspx) saying that from 2013 onward that Enable Rules also show/hide buttons AND they can also run custom javascript.  So with a Custom Javascript rule I can directly use Xrm.Page.ui.getFormType() to show/hide my buttons.

  • KG_CRM Profile Picture
    KG_CRM on at
    RE: Hide button based on access to individual entity

    I tried all of the options for FormStateRule for when Xrm.Page.ui.getFormType() returns 2 (Update) and when Xrm.Page.ui.getFormType() returns 4 (Disabled).  In both cases of Xrm.Page.ui.getFormType() the buttons only display when FormStateRule= Existing.  All other options for FormStateRule will hide the buttons.

  • KG_CRM Profile Picture
    KG_CRM on at
    RE: Hide button based on access to individual entity

    My buttons with the OrRule don't display at all when the form is 'Update' or 'Disabled' (no change from before, I think) and the buttons with the FormStateRule of 'Existing' are showing in both scenarios.

    For troubleshooting I've tried editing all of the display rules and setting their InvertResult to false, even though it should default to false, and that didn't help.  I tried adding Xrm.Page.ui.refreshRibbon() to the form's OnLoad event in case the FormState was changing and that didn't help either.  I exported the Solution and opened the customizations.xml file and the display rules appear to be defined just as I've set them in Ribbon Workbench and the Commands are referencing the Display Rules I want.

    I'm at a loss to figure out how to troubleshoot this further.  Any ideas?

  • KG_CRM Profile Picture
    KG_CRM on at
    RE: Hide button based on access to individual entity

    Mahendar,

    The name 'Existing' would make you think that, but the description for 'Existing' at msdn.microsoft.com/.../gg334563.aspx is "Used after a record is saved and the user has access to edit it."  When a form cannot be edited, then it is either Read Only or Disabled.

    I added Xrm.Page.ui.getFormType() (msdn.microsoft.com/.../gg327828.aspx) to my button's code and the form's OnLoad event and half the problem is I should be using the option for 'Disabled' instead of 'Read Only'.  Or to be on the safe side I'll use an OrRule and use both.  When the from can be edited this function returns a value of 2 for 'Update' which I think corresponds to 'Existing' in the FormStateRule, so I'm not sure why that display rule isn't working properly.

  • Mahendar Pal Profile Picture
    Mahendar Pal 45,095 on at
    RE: Hide button based on access to individual entity

    Existing meas this your button will be visible for existing record (it could be read only or not), for example if you will try to create a new record this button won't be visible until you will hit save button, so record is saved and you will be able to see it.

    Hope it will help.

  • KG_CRM Profile Picture
    KG_CRM on at
    RE: Hide button based on access to individual entity

    Apparently using an EntityPrivelegeRule to check for Basic Write access isn't what I wanted.  Instead, a FormStateRule set for 'Existing' and 'Read Only' sounds like what I want (https://msdn.microsoft.com/en-us/library/gg334563.aspx), however I've tried them and they are not working as I'm expecting.  Buttons set to display when the form is 'Existing' are displayed when the form is read-only, and buttons set to display when the form state is 'Read Only' are not being displayed when the form is read-only.

  • Mahendar Pal Profile Picture
    Mahendar Pal 45,095 on at
    RE: Hide button based on access to individual entity

    Yes, Scott is correct, I was wrong in my previous reply, if you user will have higher access level it will return true in basic as well.

  • KG_CRM Profile Picture
    KG_CRM on at
    RE: Hide button based on access to individual entity

    Thanks Mahendar and thanks Scott for your help.

  • Suggested answer
    ScottDurow Profile Picture
    ScottDurow 19 on at
    RE: Hide button based on access to individual entity

    Hi - if you select Basic then the rule will return true even if the user has a greater level of access.

    Hope this helps,

    Scott

  • KG_CRM Profile Picture
    KG_CRM on at
    RE: Hide button based on access to individual entity

    I want to show the button if they can write to the record, regardless of privilege depth.  If they cannot write to the record, I don't want to show the button.

    With a different button I also have a need to do the opposite; display it if the user doesn't have write permission, but if I understand how to do one button I can figure out how to do the other.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Daivat Vartak – Community Spotlight

We are honored to recognize Daivat Vartak as our March 2025 Community…

Announcing Our 2025 Season 1 Super Users!

A new season of Super Users has arrived, and we are so grateful for the daily…

Kudos to the February Top 10 Community Stars!

Thanks for all your good work in the Community!

Leaderboard

#1
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 292,516 Super User 2025 Season 1

#2
Martin Dráb Profile Picture

Martin Dráb 231,432 Most Valuable Professional

#3
nmaenpaa Profile Picture

nmaenpaa 101,156

Leaderboard

Featured topics

Product updates

Dynamics 365 release plans