Tricks for Removing Page Elements to Preserve the Upgrade Path in NAV
I’ve been doing a lot of work for a customer recently where they’ve wanted multiple fields taken off their Sales Order page in Microsoft Dynamics NAV (Navision). The idea seems to be that the unused fields on the page will confuse the users, who won’t know quite what to fill in for the Opportunity No. field. (Honestly, I’m only vaguely aware of what Opportunity No. is used for, myself.)
So, I’ve been asked to remove a lot of fields from all of these pages. I’ve also been thinking about the recent push from Microsoft to be doing regular small releases like hotfixes and rollups, and how NAV 2015 has a number of tools to help ease the pain of upgrades.
The best way to remove these fields from the document page is not to just delete them. Instead, you want to set the Visible property to FALSE to get them off of the page. That takes the field off of the page and doesn’t let the user show it again.
For list pages, though, you have to do things a little differently. Setting Visible to FALSE for a list page field will still let a user see it; they’ll just have to go into Show Columns first and select it. Instead, you need to set the Enabled property of the field to FALSE, and that gets it off of the page.
What if you want to move a field on a page? What do you do then? Well, you actually should still hide the original field, and then create a new field and put that new field where you want it. This preserves the upgrade path, because it keeps the original field around with the original identifiers, and then the new field can be put wherever you want. You’ll need to make sure you give the new field a distinct name, but that should be pretty easy to do.
A similar trick can be used for page actions, as well. You can set the Visible property of an action to FALSE, and that will render it unable to be chosen by a user. If you wanted to move an action around, you could copy and paste that action in the Action Designer and then hide the original; just be sure to document any code in the action properly.
This is a huge improvement over the way we had to do things in the legacy client, where form elements would just get stacked on top of one another and hidden, and moving a form element would result in something potentially incomprehensible in the compared objects. (Actually, that sounds a lot like comparing RDLC reports nowadays. There are some things you can do for that with the Report Selections table, but that’s a topic for another blog entry.)
When you’re coding and designing your elements, always try to think about the upgrade path and how the changes will look when you have to look at the customized object next to the object from the new version of NAV, and that should get you on the right path for where to go. Happy coding!
UPDATE: I received an email a few days after this blog went up from another ArcherPoint developer. She suggested some other interesting ideas for hiding page fields. You could run the NAV client in configuration mode and hide fields that way. You could also set a field to have an Importance property of “Additional”. That won’t completely block the user from seeing a field, but it will require them to hit the “Show Additional Fields” button on a page to see it. And finally, there are some options in the Easy Security add-on to allow you to hide page fields from individual users or groups of users.
UPDATE 2: In a comment about this blog post on LinkedIn, another developer pointed out that the user could actually show hidden fields in a card page by going to the Customize menu, choosing Customize This Page, then finding the right FastTab and choosing to show the hidden field. This is definitely something I overlooked, so keep this in mind if you’re hiding fields for confidentiality purposes. If you’re just trying to get the fields out of the users’ way, though, the original advice still applies. (This is why I’m a developer and not a software tester.)