CodeScan for Apex and Field Usage Report for sObjects analysis in the Bloom R17
Phew... Finally the Bloom R17 version of The Welkin Suite is ready to roll-out to you, so you'll enjoy then new great features we were working so hard last month! First of all it is the easiest way to analyze your Apex code against 180+ rules using the CodeScan tool - couple clicks and here's your comprehensive report on code quality! Won't say 'second', so next to CodeScan we are introducing you a great Field Usage Report that will help you finding out where and how your field is used and what might be the impact of any changes in it - without digging into XML files!
The built-in Task List panel will help you organizing your tasks, improved fields editor in sObjects Inspector will save your time when working with your sObjects and a bunch of other handy changes. Read more on what you'll find in the Bloom R17.
Field Usage Report
We regularly face cases when we need to find out where some field is used - either to understand possible side-effects on some changes to a field or to understand some logic or processes that happen in an organization. While each of us has his own shortlist of places to check (that takes not more than couple minutes), you'll be surprised on how many places we can miss, when asked to compile a definitive list of places where a field can be used. Our team experienced this on ourselves when we were working on the Bloom R17 version of The Welkin Suite - we've easily named 80% of most common places to look for dependencies, while other 20% were not so obvious and took a lot of time to put them on paper. This is why today we are starting our journey on implementing the ultimate all-in-one field usage report tool, that will help you to find all places where a certain field is used.
Even if you've skipped that long "intro" paragraph above - it's still clear that from now on there is a Field Usage Report tool built-in in The Welkin Suite IDE. Is it smart and helpful enough? Let us explain what it does
The IDE scans your local files and looks for field usages in different places and takes into account expressions, relations, macro usages in templates, etc. - and this is the main difference from doing just simple 'Search All' across the whole solution. For example, try searching for 'Amount' or 'Name' fields using the regular search options - you'll have so many hits of these widely used words in different places and in different objects, so it won't be very helpful.
Using this intelligent approach, the IDE can show you lots of different things in a handy way, however, it is also not the fastest option for us to implement. At the moment the IDE will look for field usages in the following items:
- Approval Processes - in all possible actions, emails, criteria, and page fields taking into account expressions, relations, macro usages. The only limitation is that the IDE does not check plain text versions of Email templates, that might be used as a part of Approval Process itself or as Email Alerts in some actions;
- Email Templates - while emails are used in approval processes and in workflows, the IDE will list them separately as well, but with the same limitation - without searching in a plain text version;
- Layouts - of course, the IDE will check if a field is included into any layout, but it also will find a field if it is present in any Related List on other layouts (however, this can have some possible limitations for standard objects);
- sObjects - virtually we will scan every part of an sObject, excluding web links: list views, compact layouts, sets of fields, formula fields, default values, rollup summary fields, filters in lookups, dependent picklists;
- Validation Rules - in both Error Condition Formula and in the Error Location field;
- Workflows - in the same way as in Approval Processes, the IDE will look for a field usage everywhere in the Workflow, where plain text email templates are the only exception.
No need to remember this list - each time you open a Field Usage Report, you will see this information in a tree-like view, so you will be aware of possible limitations, while we will keep working on extending supported locations.
Ok, let's go through the ways how you can open this report.
In the 'Admin Panel' (related documentation , just in case you'd want to go through it in more details) you will see the 'Open Field Usage Report' command in a context menu for any field. At the same time, you will see a new icon in the Admin Panel's toolbar - it will be enabled once you select any field.The same command is also available for you in the 'Schema Explorer' panel when you right-click on any field.
When you'd open any sObject in the editor and switch to the 'Fields' tab, you will see the same icon as in Admin Panel once you select any field - clicking on this button will open the Field Usage Report for that field.
When the report is opened, the IDE will show you a tree view of all places where the field is used. By default the list has the 'Object view' - all locations (except Email Templates) are shown under corresponding objects, where they are defined. In the 'Object view' it is very easy to detect logical dependencies between objects or analyze how exactly this or that field is used in different objects. If you'd like to look from another perspective, let's say - analyze the impact of a field on business logic or identify something like a character of a field (if it's an 'output' field that's only used for displaying something or if it's an 'input' field, that is used in lots of formulas and affect calculations and processes), you can switch to the 'Type view' using the corresponding toggle button in the toolbar. In the 'Type view' the location type (e.g. approval process, validation rule, workflow, etc.) will be shown as a first level in the tree, while objects and further details will take place on lower levels of the tree.
We have described where the IDE looks for field usages, but let's go through this in more details and see what exactly information is available to you.
It will be a long enough read, so we've hidden detailed descriptions behind spoilers - click on a corresponding header to read more:
Approval Processes
Email Templates
Layouts
Validation Rules
Workflows
sObject fields - Formulas, Default Values, Rollup Summary, Lookup filters, Dependent Picklists
sObject others - Compact Layouts and Field Sets
List Views
CodeScan integration
Here in The Welkin Suite we are committed to the idea of a clean code and we encourage you to use anything (or, better, everything) to help you increasing code quality (or keeping your already-high-quality code in a good shape) - starting from Uncle Bob's books and up to the automated tools that will do a dirty job for you. For sure, none of them will magically change a code and remove everything that you don't want to see there, but at least you'll know where to spend your time, fighting for a great code!
A while ago we've added PMD support in The Welkin Suite IDE, and recently we've updated the built-in PMD to the 6.0 version and added support for your custom XPath rules, so if you're a XPath-ninja and have a lot of great ideas for PMD rules - you have absolutely great tools, that will allow you to automate code checks.
But today we're giving you a great tool to go far beyond ~50 built-in PMD rules without getting your hands dirty in XPath - CodeScan .
We even won't list all categories and rules that CodeScan provides right out of the box - on the screenshot above you can see that there is a lot of interesting categories and the total number of included rules is 181! It is 4 times more rules than in regular PMD, so it's worth checking for sure!
In terms of support in The Welkin Suite, you should expect the same level of comfort as always - the built-in ruleset configurator allows you to go through all rules and configure an ideal ruleset without a need to edit XML on your own. Or, even more, you can use the built-in pre-configured ruleset by Villagechef - creators of CodeScan.
Once you have a ruleset, you can attach it to a project from a context menu in Solution Explorer and selecting 'Properties', or you can select a ruleset that will be used by default for all of your projects via the 'Tools → Options → External Tools → CodeScan' menu. Also, you will be able to enter your CodeScan license in the same section in the 'Tools → Options' window.
Afterward, all violations of your ruleset will be shown in a separate 'CodeScan Report' panel and in the regular 'Error List'.
You can find more details on what options you have for automated code analysis using CodeScan in our documentation's page for PMD , as the same capabilities are available for both PMD and CodeScan (while CodeScan provides 4x more rules!).
We are sure that it will be a great idea to grab a free trial on CodeScan's website and start exploring its capabilities in The Welkin Suite as you won't need to install or configure anything - CodeScan is bundled with the IDE from now on!
And the last thing here - we will have a joint webinar with CodeScan's founder Ben van Klinken. Join us on April 11th to find out more what other great options CodeScan provides and how you can use it in the IDE.
Task List
There are always so many tasks to do later, so many things what to don’t forget, what is not finished and should be done “right after this”, and we think you can continue this list of examples with your own ones. This applies as for a real life either for a development also! And all we know about a common approach to handle all of this leaving comments, notes, reminders, listings.
We are ready to help you with this in The Welkin Suite for Windows! One of the really required features and a nice helper to keep all the places in your code that should be refactored, fixed, implemented, changed, finished, improved in one ‘table’ - Task List.
Find the newly added 'Task List' panel in the menu View and start to track your comments.
First of all, we want to tell that even without any additional custom configurations, the IDE detects some default tasks in your Apex and Javascript code and you can see them just when you open the ‘Task List’ panel.
So at once you will find the next entries if related tokens are present in your code:
- HACK - indicates a workaround
- TODO - indicates something to be done
- UNDONE - indicates a reversal or "roll back" of previously changed or updated code
- UnresolvedMergeConflicts - indicates some modifications in a code that could not be merged
Each of the items contains the next information in the table:
- Priority shows you how important is to work on a task or you can postpone it.
- File shows a name of a file that where your task is present; this field can have as a just a file name so and a full path to the file that contains a task comment - you can configure this option and we will tell you about this in the next paragraph.
- Line is an exact line in a file that contains a token for your task.
- Description includes a token itself and a comment related to a task.
When you double click on any comment in the panel, the IDE will redirect you to a task itself in your code.
How to manage tasks
In The Welkin Suite you can use default tasks, modify configurations, or create your own just in several steps!
All the necessary settings are present here: Tools -> Options -> Environment -> Task List.
In the ‘Token list’, you can see the list of already existing tokens (for example, default ones that were mentioned above) and manage them, or add a new one. Please select any of the items and start changing its settings (name or priority) - right after any of edits the ‘Add’ button will become active and clicking on it will save your new token.
Actually, a Name of your token is an indicator for your task and is a necessary beginning of a comment in your code to create a new task that will appear in the Task List panel.
Also, you can modify any existing token easily - just select a token in the 'Token List', edit its name, and press ‘Change’. The similar way you can use for removing tokens - select the necessary one and click the 'Delete' button.
Two more additional settings in the options for your managing your task list are the next: 'Confirm deletion of tasks' and 'Hide full file paths'. By default, both of them are checked, however, if you don't need this - you can disable it exactly here.
User’s tasks
You can admit that on the top of the Task list panel there is a drop-down menu where by default is selected Comments. One more item in this list User Task.
Here you can create your own ‘ToDo’ things or leave comments and task for future that is not related to your codebase.
As you can see, configuration values are the same:
- Priority - how important a task is for you: high, normal, or low; for simple orientation, you will see an appropriate priority as an icon for high and low tasks;
- Description - type what you need and don’t keep in mind to remember all of this :)
You will find a ‘Create’ option at the right top corner of the panel as an icon.
When you complete any of these tasks, just simple mark a checkbox neat it and this will be ‘done’. To delete unnecessary items in the list you can use its context menu.
We save all your user tasks in an appropriate project folder in a ‘*.usertasks’ file, so please take this into account if you would like to store your project in Git, or other repositories.
Other changes
To provide you with an ability to use all the updates and new opportunities from Salesforce, we have upgraded The Welkin Suite Bloom to support the Salesforce API version 42. So already now you can be sure that there won't be any conflicts in your working process related to an API version from your organization and you will be able to work in the IDE using all Salesforce features with their latest changes.For example, in a frame of this, all new objects, types, fields, etc. that havecame with API v.42 will be accessible for you not in files in your TWS project only, but in the code completion suggestions also!
The next set of changes and improvements is dedicated to a work on sObject fields and these changes will help Salesforce administrators who use The Welkin Suite IDE. This time, to be honest, the changes are not such a significant, however, we think, they are pleasant and will make some usual actions more inconspicuous First of all, we have changed the presentation of the sObject Fields Editor - now it has a vertical separation for an easier navigation in a list of your fields and your work on any of them.
After this, when you create a new field in your sObject directly from TWS, you will get an API name field filled automatically after typing a Label for this object. This was already so much usual when you worked in Salesforce on your organization, and now you can don't care about it in The Welkin Suite IDE - we will do this for you. And no additional typing!
Have you already used the Tracking changes functionality presented in the previous version of The welkin Suite Bloom? We will be happy to hear your feedback about this! Meantime, while waiting for requested improvements, we have changed colors to make UI of the Tracking changes panel more smooth.
And let's talk about fixes in The Welkin Suite Bloom R17.
While you were working on Lightning components and applications directly from the Lightning Bundle Explorer, you could be faced with a crash of the IDE when opening files. There was a workaround to open the same files from the Solution Explorer, however the fact of crashing stayed. We have fixed it. Also, regarding the Lightning Bundle explorer, we have a question to you: do you use it frequently, and what do you think if we would move an option to create aura files to our great Lightning editor with the reviewer? Looking forward to your thoughts!
The next crash of the IDE that we have fixed occurred when you worked on configuring PMD rulesets and used the filter. Now you won’t be faced with this issue also.
Previously in the Admin panel there were missed Validation Rules that contained a field MasterDetail and custom objects that had a namespace prefix. Also, FLS settings could be absent for a sObject with a namespace prefix. Our developers have solved all of this in The Welkin Suite Bloom R17 and now you will get all the necessary data.
In addition, as for sObject FLS inspector, we fixed the issue when a toolbar with all the options disappeared after resizing of the editor window.
Full list of changes
Features
- Implemented the integration with CodeScan for code analysis
- Implemented the Field Usage Report for dependencies and usage analysis
- Implemented the Task List with automated Comments scanning and User's Tasks
- Implemented an In-App subscription Purchase
Improvements
- Updated The Welkin Suite IDE to support Salesforce API v.42
- Implemented a prefilling of API name for a sObject during its creation by default
- Changed the view of the sObject Fields editor from the vertical separation to the horizontal one
- Changed colors in the Tracking Changes panel to make TWS UI more smooth
Fixes
- Fixed the crash of TWS when opening lightning files from the Lightning Bundle Explorer
- Fixed the issue when the toolbar in the sObject FLS Inspector disappeared when its size was decreased
- Fixed the crash of TWS after using the filter in the 'PMD Ruleset Configuration' window
- Fixed the issue when a Validation Rules that contained a MasterDetail Field was absent in the Admin panel
- Fixed the issue when a custom object that had a namespace prefix was absent in the Admin Panel
- Fixed the issue when the FLS settings were absent for a custom object that has a namespace prefix
- Fixed rare cases of TWS crash due to unhandled exceptions when closing a new project
- Fixed rare cases of the crash of TWS when discarding changes in the Pending Changes panel
Your comment may be the first