As it stands now, if you have an Entity Form on more than one page, you’d have to copy the CSS to more than one page as well (or better yet, include a reference to a Web Template that contains the CSS in more than one place). That way we could follow my best practice of always putting JavaScript/CSS is the most reusable place possible. By using the developers tools included in your browser, you can easily discover the class of the element you want to target.Īs an aside, I wish that Entity Forms, Entity Lists, and Web Forms had Custom CSS attributes like Web Pages do. This is most important for areas where we don’t really have control over the way functionality is rendered, like forums, idea, and blogs. In this situation, I targeted the parent “notes” and “note” classes just to ensure my rule only applied to this area, in case the “createdby” class was used elsewhere.Īfter dropping that CSS rule in the Custom CSS attribute on the Web Page, the Created By section disappeared as expected.Īs I said, the Portal product team has done a great job of including classes that make it easy to target elements we might want to change. Therefore, the following rule should work to hide it:
In our case, they wanted to hide the “Created By” area, which we can see has a class of “createdby”. You can see that all of the various elements have class attributes which makes it easy to target them with CSS. The markup used to display the note look something like: The user was asking for some JavaScript to do this, but my first thought was to use CSS instead.
#SECURITY THROUGH OBSCURITY MEANING HOW TO#
In this case, the user wanted to know how to hide the “Created By” area that appears when you display the notes related to a particular record on an Entity Form. The Portal product team has done a great job of including CSS classes pretty much everywhere we’d need them.Īs an example, let’s look at the Dynamics 365 Community forum post that inspired me to write this blog post. Thankfully, the way that the Dynamics 365 Portal product has been developed makes using CSS really easy in a lot of cases. While the Dynamics 365 Portal product can handle a lot of the styling due to its use of Bootstrap, projects do, more often than not, require some sort of custom CSS.
As it is often a customer-facing tool, extra emphasis is placed on the interface. However, this isn’t so true with the implementation of a Dynamics 365 Portal. While you may use JavaScript to perform custom business logic, Dynamics 365 usually handles the interface side of things, and you could go through many successful Dynamics 365 implementations without ever needing to write a line of CSS. Many CRM developers may not be overly comfortable with CSS – it’s not something you typically need to use a lot when working in Dynamics 365. However, if you’re simply trying to hide something all of the time (because maybe there is something that comes out-of-the-box that you don’t want to show users), I’d strongly recommend considering CSS. In this case, JavaScript would work well. you want to build some logic that determines if a field is hidden or not). This includes situations where the visibility of something is conditional (i.e. In some cases, JavaScript is a great choice. So if there is something on the page we want to get rid of, should we take the same approach? Those familiar with the Dynamics 365 Portal offering know that it doesn’t respect business rules, and often we are wanting to hide elements on a portal that aren’t necessarily related to a CRM form. Even since then, if you want to hide entire tabs or sections, JavaScript is the way to go.
Before the introduction of business rules in Dynamics CRM 2013, developers used to use JavaScript all of the time to conditionally hide fields on the form.
0 kommentar(er)
