120+ supported metadatas, project from sources, and others in The Welkin Suite Bloom R19
The Welkin Suite Bloom R19 version is dedicated to covering all of the known issues and imperfections in the teamwork organization for non-SalesforceDX projects, and much of this is based on a lot of feedback from our community- thank you to all that sent ideas and pain points!
It is a huge challenge to highlight anything that was introduced in this release as somehow more important than anything else, as all of these changes were requested and are quite honestly required for a comfortable work with Salesforce projects in complex environments. So due to the significant amount of changes that we made, we'll just list them off without any additional description - so you can find what would be the interesting areas to you and then you can read about them in more detail below.
So the main changes in the new version of the IDE are (the links will lead you to the correct section in the article):
- More than 100 metadata types are added to the list of supported metadata types
- Added a new cool approach to work with such a large amount of metadata types - metadata working set
- Introduced the freedom to reconnect your Salesforce project to any organization in seconds
- Added an option to create (and maintain) TWS projects directly from sources (e.g. from your Git repository)
- Significantly reworked our deployment functionality
- Introduced the deploy-on-save option
- Significantly reworked our pull functionality
Some of the smaller, but still important changes are:
- Changes in the 'Project metadata components' wizard and a new approach to work with managed packages
- Project's context menu reorganization
- 'Find usages' in Apex, and 'Field usage report' updates to include SOQL
- Some other code completion changes
Taking into account the scale of these improvements - you will notice a lot of changes in the IDE, so please read these release notes to get to know all of them in detail!
Extended metadata types support
In the last years we had a lot of constructive discussions with awesome Salesforce developers regarding the list of different metadata types that should be supported by the IDE, and it appears that there is not any one-size-fits-all set of metadata types... other than everything This is why we are making such a huge step towards that goal and as of now The Welkin Suite supports 128 different metadata types as a part of a project.
This means that you are now able to include everything (or almost everything) from your organization into a project, so you will have a full snapshot of your organization on your PC, or you can push all of this into a Git repository, so you will have the full history and full control over your sources, and what and how to deploy to Salesforce:
- For your existing projects (or for any projects that you will create in the future) you can configure what is included into the project in the 'Configure project metadata components' wizard, which is available from the Main Menu → Project, or from the context menu in the Solution Explorer.
- For new projects created as a copy of your organization, you will be able to configure this in a familiar way in the second step of the project creation wizard.
However, with such an amount of new items that can be included into the project, it is very important for us to keep the performance up (of both the IDE and your own performance), at least in needs to be at the same level as it was prior to Bloom R19, so we have made some very significant changes in the way of how exactly the different metadatas are included into the project - read about this below.
Metadata working set
Previously in The Welkin Suite, there was only one major option for metadata - include it into the project (either as a defined list of items or the 'subscribe' option) or not to include it, and this approach was absolutely ok when you are working with only most common metadata types in Salesforce. However we are absolutely sure that the intensity of operations, for example, with Apex Classes is significantly higher compared to the intensity of operations with Remote Site Settings, but you still may want to have Remote Site Settings in your project. Such a difference in the ways how developers are working with metadata types, can now be reflected in the project metadata configuration using one of the 3 main options:
- Include a given metadata type into the project as a part of 'working set'
- Include a given metadata type into the project as a part of 'other metadata'
- Exclude a given metadata type from the project
The most precise project configuration can be achieved by using both Metadata the working set configuration and the Project metadata components - in the first, you can define the most important metadata types, while in the second you include/exclude only the needed metadata types (from both sets).
You can configure the working set configuration in multiple different ways:
- In the project's context menu in the Solution Explorer select the 'Configure metadata working set'
- In the 'Project metadata components' configuration wizard click on the cog wheel in the upper right part of a window to access the metadata working set configuration
Let's highlight the differences in the IDE behavior for the 'working set' and 'other metadata':
- Regular deployment (yes, we have renamed the 'Build' command, don't be scared) will deploy only the items from the metadata working set;
- Regular pull will check for changes and new items (for subscribed metadatas) only for metadata types that are in the working set;
- There are additional options for full deployment and full pull that will do the same thing, but for all metadata;
- There are other new options to perform pull and deployment that will give you even better control, but we'll highlight them in the later sections;
With such behavior differences, this metadata separation allows you to drag into your project a couple thousand more items without losing any second in the regular IDE operations that you are doing hundreds of times a week - deployment and pull.
And even if you don't include the hundreds of different metadata types into the project you can still benefit from the 'working set' separation. Let's say you are doing mostly Salesforce configuration and care about Apex, Visualforce and Lightning much less compared to sObjects, Validations, Workflows, and Layouts - no problem, just configure the working set to include only needed metadata types, while everything else that you're using from time to time, add to the project as other medata. By the way - the reverse example works in the same way
New awesome deployment options and even better performance
As we've mentioned in the previous section we've renamed the 'Build' option, so now it is called 'Deploy', but as you might guess - renaming it is not the most important change related to this process, so let's go through all of them.
First of all, we have removed the 'Deploy objects' command and modified the new 'Deploy' command to handle all metadata types, so no matter what you have changed - it will be deployed the next time you hit F5 or use the 'Deploy' command from a project's context menu. This change is also reflected in the redesigned 'Pending Changes' panel - all changed files will be listed in the panel. You might also notice the working set/other metadata separation in the panel.
In the redesigned 'Pending Changes' panel, you will also find a couple new options and the most important one is an ability to select certain files to be deployed separately. For example, if you've made changes in 20 different files but due to some reasons you want to deploy only one or a couple of them to your Salesforce organization - just mark the checkboxes next to them and hit one of the 'Deploy' buttons in the toolbar. The same options are available for each file individually using buttons in the 'Action' column:
- 'Discard' - discards your changes in a file and reverts it back to the state when it was last retrieved from the Salesforce organization
- 'Compare' - compares a file in the current state with the state when it was last retrieved from a Salesforce organization
- 'Deploy' - deploys a file using The Welkin Suite's regular process that checks for conflicting changes on the organization and blocks deployment is a file was changed by someone else the organization. This option is only available for items that are a part of the metadata 'working set'
- 'Force deploy' - deploys a file, ignoring any checks on the organization, thus it overrides the contents of a file on the organization with the one you have in your project. This option is available for both 'working set' and 'other metadata'
We have also added a 'Force deploy' approach to a project's context menu, so you can access it from virtually anywhere.
Isn't it cool to have such tight control over your deployments? Just to make sure that we won't hear 'nope', here's one more way to quickly deploy your changes.
'Deploy file' and 'Force deploy file' options are added to context menus of all editors in the IDE, thus you can deploy only the file you are working on in a very quick way. The 'Deploy file' option is also available using the 'CTRL+B' hotkey.
And now the dessert - the most requested deployment option Yes, it is 'Deploy on save'! By default, The Welkin Suite does not deploy files to Salesforce once you save them, but if you're a fan of this approach and you were missing it - it's only a few clicks away. In the Main Menu → Tools → Options navigate to the Deploy → General and you will see the following options:
- Deploy Salesforce Project item on Save Selected - automatically deploys a file after it is saved
- Deploy Salesforce Project on Save All - automatically deploys all changes that are shown in the 'Pending Changes' panel after the 'Save all' command is executed
- Deploy DX project on Save All - the same as previous, but for Salesforce DX projects
- Deploy Analytic Project on Save All - the same as previous, but for Salesforce Analytics projects
But wait, there's more!
We have made a couple significant performance improvements to the deployment process itself, starting from a more intelligent selection of API's to use under-the-hood, and up to a reduced set of requests sent to Salesforce as a part of the deployment process. This is why you will get a couple times faster deployment for cases when you are deploying only code (Apex, Visualforce, Lightning), while for all other cases the performance boost won't be so awesome, but still noticeable!
Updated 'Pull' functionality
Let's stop for a few minutes to take a look at the changes to the 'Pull' process, so we'll cover all changes to the core operations in the IDE.
Starting from the Bloom R19 version of The Welkin Suite you will find 3 different pull options in a project's context menu, instead of only the one in the previous version of the IDE:
- Pull working set from Salesforce - retrieves changed files from Salesforce for metadata types that are included into the working set and retrieves new files for metadatas from the working set where you have 'Subscribe' enabled
- Full pull from Salesforce - retrieves changed files from Salesforce for all metadata types and new files for metadatas where you have 'Subscribe' enabled
- Force pull from Salesforce - retrieves files from Salesforce for all metadata types no matter if they were changed in the organization since last pull or not, however, it does not retrieve new files (e.g. does not include 'Subscribe' option)
With these 3 options, you can choose the most appropriate and time efficient for you to get updates from your Salesforce organization. For example perform a full pull before you committing to git, while it might be best to use the working set pull in most daily activities.
In addition to these changes, you can also find some changes in the editor's context menu - in the context menu for any opened file you will have 2 options:
- Pull from Salesforce
- Force pull from Salesforce
Both these options are skipping the first screen of a pull process, so they immediately start retrieving changes or looking for changes. 'Force pull from Salesforce' will overwrite your local version of a file with the one from your organization no matter if there were any changes on the Org. 'Pull from Salesforce' in its turn will check if there were any changes on the Org and will retrieve them only if needed. However, both of these options, when executed from a context menu in an editor, won't check for new files (e.g. 'Subscribe) thus ensuring that you will have your file retrieved as fast as possible!
One more small change for the Pull process is related to the first screen of the Pull wizard - we've organized it into a nice hierarchical view so it will be much easier for you to fine-tune the pull settings in the wizard.
Connecting a project to any Salesforce organization
In The Welkin Suite Bloom R19 we are releasing one of the most significant changes in the IDE's behavior and functionality - in short, TWS projects can be disconnected from an organization and (re)connected to any other Salesforce organization in a very easy way. As a part of this reorganization we have also implemented some other important changes, so just to name a few:
- Moved credentials out of the project file to a secure OS-wide credentials storage
- Moved the Salesforce org information about files in a project out of the project file
But before we'll go through the process of connecting a project to an organization, let's take a look at the benefits and abilities that these change altogether will give all of us.
First of all we've kept in mind teamwork and Git (or any other source control system) usage - getting rid of the strong project ↔ organization connection allows different developers & admins work on the same codebase with different Salesforce organizations, while details about project ↔ organization connection can be stored separately by each developer and not committed to a repository.
At the same time in very dynamic environments where sandboxes or development orgs are spawned & killed very often, it was sad to recreate project with each organization change, even when sources remained the same. With the current approach to handling projects in The Welkin Suite, it won't be a problem at all, and you'll be able to switch between orgs even hundred times per day
So what do you need to do to reconnect any of your projects (even the ones created in previous versions of the IDE) to a new Salesforce organization? Open your project and in the Main Menu → Project or in the project's context menu in the Solution Explorer select the 'Connect to an organization' command.
In the wizard that will open, you will need to enter the credentials of your organization that you'd like to connect to your project and press 'Next'. Once credentials are validated, the IDE will do the following:
- Compare the items in your project with your organization, and the local files that are not available in the organization will remain in the project, and will be deployed to the org on the first deployment
- Retrieve all matching items (so be prepared, this can take some time depending on the size of your project)
- Calculate the hashsum for each local and retrieved file, and then compare them. Here, we've taken into account your previous feedbacks, so the IDE will 'virtually normalize' line-endings before calculating the hashsums, so it won't show you any false conflicts due to the differences in line-endings.
- Will detect conflicting files
- If the IDE detects any conflicts, you'll have multiple options to handle them.
On the 'Conflicts resolution' step, you will see the following information for each of the conflicting files:
- 'Diff' button to see the difference between files
- A checkbox to use a remote version of a file
- File type
- It's path within the project
- The status will show if a local, remote, or a merged version of a file will be used in your project after connecting it to your organization
- A 'Merge' button to launch an external merge tool to resolve the conflicts manually
After you handle all conflicts and finish the wizard - your project will be connected to the organization. All files that are missing from the remote organization, as well as all merged conflicts and files for which you've used the 'Local' version, will be automatically added to the 'Pending changes' list and will be deployed to the organization on the first deployment.
Create The Welkin Suite project from your existing sources
In the Bloom R19 version of the IDE, you will find a new option in the standard project creation wizard, so when you'll open in the Main Menu → File → New → Project you will see an option 'Salesforce Project from sources'. Now just enter the project's name and proceed to the next step.
Ok, so on the next screen you will need to fill in some information. First of all, you will need to point the IDE to where your sources are located - you can just copy-paste the path to the 'src' folder, or you can look for it right there in the wizard. After that you'll have two options:
- If you would select the 'Create a project file close to sources' - the IDE will create a .sfproj file in the folder where your 'src' folder is located, and it will work directly with those sources
- If you would select the 'Copy source to project folder' - the IDE will copy those sources to the Location that you've selected in the previous windows, and the sources in the folder that you've selected, won't be modified by the IDE at all
So no matter if you will create a project in the same folder as your sources, or if you'll select to copy your sources to the project's location, the IDE will perform some additional actions, once you'll proceed:
- The IDE will scan the 'src' folder and compare it with the 'package.xml' file that's located in that folder
- If local files and 'package.xml' content match - great, the IDE won't change your package.xml
- If local files are different from what you have in the 'package.xml' file - the IDE will create a 'package.xml.bak' backup of your file, and then it will craft the new one, that matches your local files
- The Welkin Suite will unpack all the static resources and will store the unpacked content in the 'resource-bundles' folder on the same level as the 'src' folder
- Obviously, it will create the project file
Once this process completes, the IDE will open your new project and it will notify you that it's not yet connected to any Salesforce organization.
At this stage you can close this notification and examine your project, freely read it's content and even do some editing with our Code Completion working, however when you'll need to run tests/check the code coverage/deploy or retrieve changes you will need to link your project to some Salesforce organization as described in the previous section.
By the way, there's an article to read a bit more about the whole process of creating a project from a Git repository, linking it to an organization, and working with Git afterward - check it out here.
Refresh a project according to local sources
The final touch to the full freedom of working with your existing sources in The Welkin Suite IDE is an ability to reflect source changes in the project.
Another very common use case for such action looks like this - imagine you have a project and you have some Apex classes for common functionality like test data generation, scheduled jobs dispatcher or some cool trigger handler pattern implementation, and you want to reuse it in your project. The most obvious way will be to copy that class(es) into your project folder and let the IDE do some magic. Sounds good? Let's now see how to do this!
In the project's context menu in the Solution Explorer or in the Main Menu → Project select the 'Refresh project according to sources' command and click on it. This will start the process that will scan your source folder for the project and detect any changes in the list of files. The process won't scan for changes inside of files, as this is done automatically all the time and any differences are immediately reflected in the 'Pending changes' pannel.
In case the process will find any new or deleted files in your sources folder that are not present (or not yet deleted) in a project - you will see the list of such detected changes.
On this screen, you will need to mark the checkboxes for the items that you want to be applied to your project. Once you are ready, hit the 'Next' button and The Welkin Suite will apply these changes to your project.
For the new items, the IDE will do the following:
- Check for an item with the same name in your organization, and if present there - will link your new file with the corresponding ID / Salesforce item
- If an item is not present in your organization, it will appear in the 'Pending changes' section and it will be deployed to an organization on the next deployment
Please take into account, that at the moment The Welkin Suite won't create new Aura components, applications, and some of the 'declarative' items like sObjects using the regular deployment, however, as a lifehack you can use the 'Deploy to organization' wizard and deploy those files to the same org.
Project's context menu reorganization
Yup, we're highlighting such a cosmetic change separately, as we are also not very happy when menus are reordered too often, but we really want to highlight separately, that we've spent some time for this release of the IDE on trying to arrange the project's context menu in the Solution Menu and the project's section in the Main Menu to be as friendly and intuitive as possible. We hope that it'll be easier for you to navigate in the updated menu!
Project metadata components configuration wizard and managed packages handling
Since we've introduced support for managed packages in The Welkin Suite we've heard some helpful feedback on how to make your work with managed packages, as a part of a project, more comfortable. At the same time, 100+ new metadata types supported by the IDE required some fine-tuning in the good old 'Project metadata components' wizard. And we've made this changes
First of all, we've made a couple small but important changes:
- It's not required anymore to wait till the information about all metadata types will be loaded by the IDE - you can make your changes and apply them immediately without waiting. The same applies to the project components selection during the project creation process.
- You will see the full list of metadata types in the list where you have an ability to subscribe to any of them (but only if such a type is supported by your organization) no matter if there are any items of such metadata type available on your organization.
- We have also marked the metadata types that are included into the working set with an asterisk, so you won't miss them in the list
- You can find a small cog button in the upper right corner of the Project Metadata Components wizard - it will open the 'Metadata working set configuration' window
However, the most important change is that now each metadata type is separated into 'Organization items' and different managed packages, which you have installed in your organization. This means that you have much more freedom in including different items from your Salesforce organization into The Welkin Suite project - you can easily include sObjects and classes from any managed package, while not include various other items from that project, so it will be at least a bit smaller.
Find usages in Apex and Field Usage Report update
We've enhanced our Apex parsing engine and starting from the Bloom R19 version of The Welkin Suite, we are taking into account variables usage in your SOQL queries, so whenever you use the 'Find usages' functionality in Apex, it will also look inside queries and provide you information about such usages.
At the same time, we have done a very similar change to one of our favorite time-saving features - 'Field usage report'. Just to remind you - it searches for field usages in a lot of different places in your project like Validation Rules, Formula Fields, Approval Processes and, of course, Apex. As you might guess - starting from now on it will also show you when a field is used in any SOQL query.
What should be the next location to include into the Field Usage Report? Let us know your opinion!
Switch in Apex and other code completion improvements
Are you one of those developers who was waiting for so long to start using the 'switch' operator in your Apex code? Even if not - it's still a very handy operator and it is cool that we have such ability in the new Apex version. The Welkin Suite's code completion won't be surprised once you'll start using it and even more - it'll help you use the new syntax around the 'switch' with its code completion.
We have also updated our code completion to refer to the latest API version for Apex, Lightning, and Visualforce.
Additionally, in the Lightning completion 'event' and 'implements' attributes are now triggering the code completion with available events and interfaces respectively, so you don't need to remember all of them!
Of course, we have fixed some minor issues or weird situations in the code completion's behavior, but they're so small, so we won't focus on them in details here.
Other changes and fixes
We'd need to put a 'secret' promo-code for those of you who've read everything till this point, but with 'navigation' links in the beginning of this release notes it's not as interesting So we'll just highlight here some of the other changes and fixes that our team have made as a part of this release.
The first change in this list is the most related to the scope of this release - we have increased all network timeouts for long-running operations like downloading a project from Salesforce, pulling changes from Salesforce or deploying changes to an organization. So if you have a really big organization with gigabytes of sources - it should work it's way to you no matter what. Another change is for those of you with a lot of unit tests - even if you have more than 2000 test classes The Welkin Suite will handle such situations correctly and it will allow you to run all or any of them.
Some other changes are related to the 'Debug Logs' functionality - previously in some cases the IDE was not showing some of the debug logs, however it won't hide any logs from you anymore. We have also fixed some typos in the error messages after configuring debug log levels as well as have fixed weirdly looking dropdowns with log levels - they were completely white and not readable.
The last change in this list is a fix for some rare situations when the IDE might have crashed when copying results from the SOQL results window.
We hope that with all cool stuff in this version of the IDE you will have even more freedom and power to complete your Salesforce development and configuration tasks fast and with a smile on your face!
Full list of changes
- Added support for 100+ additional metadata types available in Salesforce
- Added an option to create The Welkin Suite projects based on existing sources
- Added an option to connect or reconnect projects to different Salesforce organizations with a powerful wizard
- Added an option to refresh projects according to source files changes
- Added the force pull option to force retrieving of changes from a Salesforce organization
- Added the metadata working set configuration to separate metadata in the project to the 'common' and 'other' groups for faster access
- Added the force deploy option that deploys files to Salesforce without any conflict checks
- Added the 'Deploy on save' option for files and projects
- Added an option to select and quickly deploy certain files from a project to an organization
- Added support for the Apex switch construction in the code completion
- Updated the way how 'Pull file from Salesforce' works, when called from a file's context menu in the editor
- Updated the 'Pending changes' panel with a better structure and more actions
- Updated the deployment process to be more intelligent and choose the best available deployment strategy according to the changes
- Removed the 'Build' and 'Deploy objects' commands and replaced them with the unified 'Deploy' command
- Significantly improved the speed of the deployment process
- Updated the 'Pull' wizard with the new first step window that shows a hierarchical structure of a project instead of a flat list
- Updated the 'Project metadata components' wizard and the project creation process, so it is possible to proceed further without waiting for all metadata information to be retrieved
- Updated the 'Project metadata components' and the project creation process to show metadata types even without any items of such type
- Reorganized the project's context menu in the Solution Explorer and the Main Menu → Project menu to be more logical
- Updated the Apex, Lightning, and Visualforce code completion to reference the latest version of APIs
- Updated the Find Usages functionality in Apex to look for variables usages in SOQL queries
- Added SOQL queries in Apex, as one of the search locations to the Field Usage Report
- Added the appropriate code completion in Lightning for 'event' and 'implements' attributes
- Removed encrypted Salesforce organization credentials from .sfproj files
- Significantly increased timeouts for all long-running operations like retrieving files from Salesforce, deploying changes, etc.
- Fixed the issue when only first 2000 test classes were shown in the Tests Runner
- Fixed the issue when the IDE was not showing some debug logs in the 'Debug Logs' panel
- Fixed the issue when the Debug Levels dropdown items were completely white and not readable
- Fixed some typos in the Debug Logs panel
- Fixed a rare case of a possible application crash when copying results from the SOQL Results window
- Fixed various minor code completion issues