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:
In the case, when a field is used in one or multiple approval processes - you will see ' Approval Processes' node in the tree on the left side of the report. In the 'Object view', you will see the list of approval processes where the field is used as child items, while in the 'Type view' you will see the list of sObjects as child items and approval processes on the second level.
All occurrences within an approval process are grouped into the following categories (child nodes):
- Entry Criteria - child nodes for this group will be different criteria where the field is used.
- Final Approval Actions - child nodes for this group will be 'Field Update' or 'Email Alert' actions included into the corresponding group of actions in your approval process.
- For field updates, the IDE looks in both the field, that will be updated, and in the formula.
- For email alerts, the IDE looks in the 'Recipients' setting and in the HTML version of a template, while ignoring a plain text version of a template.
- Final Rejection Actions - the same as above.
- Initial Submission Actions - the same as above.
- Recall Actions - the same as above.
- Step Approval Actions - the same as above. Please note that actions are not grouped by steps here - all approval actions from all steps are shown as child nodes for this group.
- Step Rejection Actions - the same as above.
- Approval Page Fields
As you select any 'occurrence' (a last item in the tree hierarchy) in the left part of the report - you will see its details on the right part of the screen. Usually, TWS gets these details directly from an XML representation of an item, so you will be able to see all needed information. As well as double-clicking on any occurrence or selecting any of them and clicking on the 'Open in editor' button - the IDE will navigate you directly to a file and line where this usage was found, being it field update, email template, criteria, or anything else.
When your field is used in one or more email templates - the Field Usage Report will show you all of them under the ' Email Templates' node.
Information about email templates is simplest across the locations where the IDE looks for field usages, so there is not so much to say about it, to be honest.
- Each occurrence of a search field will be shown as an item within the 'Email Templates' node.
- Right now only HTML versions are scanned.
- The 'Open in editor' command will open a corresponding *.email file direction a line where the field is referenced.
- Email templates are always shown separately, no matter if you're in the 'Object view' or in the 'Type view'.
One of the easiest locations to check yourself is to detect if the field is used in layouts, however, this would true only when we do not take into account related lists. This is why you can see the ' Layouts' node, with the following details:
- In the 'Object view', 'Layouts' will be present as child nodes for corresponding objects;
- Inside the 'Layouts' node you will find a list of Layouts where your field is used;
- Each layout in the list contains the following sub items:
- Name of the section, where the field is used on the selected layout;
- 'Layout Related Lists' item, that shows you that the field is included as a displayed column into a related list on the selected layout;
As usual, double-clicking on a last item in the tree hierarchy will teleport you into the editor directly to a line in a file, where the field is used.
But wait, that's not all about layouts
If you'd select any layout in the tree on the left side of the report - on the right (details) sided you will see the full list of fields that are shown (and not shown) on the lyaout, their attributes and in what section they are shown. Exactly how you'd see this int he Admin Panel, with the only difference that the search field will be highlighted in bold.
In the 'Object view', the Field Usage Report shows ' Validation Rules' as a child node for sObjects where they are defined, so you can quickly identify if, let's say, fields from your Account object are used in any validations in the Contact object.
Once you expand the 'Validation Rules' node, you will see a list of validations where a field is used (within an object), and for each of them you can get one or both of these occurrences:
- 'Error Condition Formula' means that a search field is used as a part of a formula;
- 'Error Location' means that a validation error message is displayed near a search field.
Once you select any of these two items - you will see details of a validation rule on the right side of the report.
Even with the Process Builder in place, Workflow Rules are essential for many organizations since a lot of business processes automations can be done in a good old way. Taking this into account, searching across workflows is an absolute must-have, so The Welkin Suite not only looks for field usages in workflows but also provides you with results in a very handy and intuitive way.
- Alerts - will show you all Email Alert actions, where a search field is used in an HTML template or as a 'Recipients' field.
- Condition - will show you a formula that is used as a condition for entering that workflow, if a search field is referenced in an expression.
- Field Updates - shows a list of Field Update actions, where a search field is an updated field.
- Field Updates Formulas - includes a list of Field Update actions, where a search field is referenced in a formula used for a new value for a field.
Don't forget that you can double-click on any 'last' item in the report tree and the IDE will navigate you directly to a line in a corresponding XML (or any other) file, where an item is defined.
Whenever your search field is used in any other field in your organization - The Welkin Suite will handle this situation and will highlight you such case.
There's no so much to explain, as it is pretty simple and clear, but anyway:
- If your field is used in any expression in a formula field or as a default value.
- If a field is used in a rollup summary field.
- If it's used as an expression within a lookup filter on the same or another sObject.
- If a search field is a picklist and if it is controlling or controlled by any other picklist
When you'd double-click on any field in the Field Usage Report, the IDE will open its built-in sObjects inspector where you'll be able to modify a field using plain XML or a GUI editor.
To finalize the picture of your sObjects, the Field Usage Report also shows all occurrences of your search field in Compact Layouts and Field Sets, displayed under the corresponding nodes.
When you select a compact layout or a field set where a field is used - the IDE will show some basic details of an item on the right side of the report, while double-clicking on a compact layout or field set will navigate you to a corresponding XML file.
While being a part of sObjects from both technical and logical side - we'll describe ' List Views' separately, as there's a bit more information about List Views, compared to fields, for example.
Once you expand the 'List Views' node, you will see list views associated with a certain object, that use a search field in one of two ways:
- 'List view column' - when the field is shown as a List View column.
- 'List view filter' - when the field is referenced in a filter expression, used for a certain List View.
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.
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.
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.
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.
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
- 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
- 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
- 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